10 ms·

Screen still works. I use it all the time. Do you have decent examples of it failing to work? If so, then that sounds like a bug against screen. The link yo

Screen still works. I use it all the time. Do you have decent examples of it failing to work? If so, then that sounds like a bug against screen. The link you provide is absolutely huge and from three years ago. Please give me a simple "stages to reproduce ..." style report. Please keep it simple and short and I'll fill in the blanks if I can and only trouble you for stuff I'm too daft to work out.

throw0101a 7y ago
> Do you have decent examples of it failing to work? Poettering: > Note that in some cases it might be a good thing to kill screen sessions when the user otherwise logs out […] * https://lists.freedesktop.org/archives/systemd-devel/2011-June/002624.html https://lists.freedesktop.org/archives/systemd-devel/2011-Ju...
- cmeacham98 7y ago
  This is such a classic example of the type of argument I see from most anti-systemd proponents that it made me laugh out loud when I clicked your link. For the lazy, here's the context of that cherry-picked sentence: > In order not to break screen we currently do not set kill-user=1 or kill-session=1. > Note that in some cases it might be a good thing to kill screen sessions when the user otherwise logs out (think university, where students not logged in on a workstation should not be able to waste CPU), in other cases its a bad thing however (i.e. in yours). That means it must be configurable whether screen is considered an independent session or not.
  - throw0101a 7y ago
    Translation: We broke long-standing POSIX/Unix behaviour of noHUP and think that's a good thing.
    - Spivak 7y ago
      I mean that is their position yes. It’s a good default too since it’s weird that “logging out” doesn’t imply “and end all my programs.” This is basically the same behavior as Windows where anything not going through the task scheduler ends when you log out. This is a feature that sysadmins have been asking for. On any multi-user system you run into this crap where background processes for users who are long-since gone just hang around forever because they do weird things or hang and ignored the signal. We implemented it ourselves with PAM but systemd’s solution is a lot cleaner. And they’re not breaking any POSIX behavior. Nowhere does it say when the system isn’t allowed to kill a process.
      - ycombobreaker 7y ago
        > it’s weird that “logging out” doesn’t imply “and end all my programs.” Weirdness is in the eye of the beholder. I regularly run programs whose lifecycles are not in sync with my login session. Why do I need to stick around to see a batch job complete? I can understand that different folks have different backgrounds which changes expectations... but come on... somebody bringing up tmux, screen, etc. should simply end the conversation. "Oh, that is a common and historical use case that I have not considered, today I learned something."
        Supermancho 7y ago
        >> it’s weird that “logging out” doesn’t imply “and end all my programs.” > Weirdness is in the eye of the beholder It's a windows acolyte mindset. Many people don't imagine that a login is just another program, rather than the parent process.
        Spivak 7y ago
        Yes but that model conflicts with the human notion of being “logged in” to a system. And the current behavior is literally what you describe. It’s just the quirk of subreapers being implemented recently that daemonizing a process wasn’t local to your session. It makes zero sense that a process that double forks is reparented by init instead of your session leader. If how things worked currently was proposed today it would sound crazy.
    - deleted 7y ago
      [deleted]
  - dooglius 7y ago
    Why exactly should students not be able to use CPU cycles while not logged in? I certainly did this as a student and would probably not have complained if it decided to kill my processes when doing so.
    - Spivak 7y ago
      You don’t deserve the downvotes. This is precisely the use-case this feature is good for. Multi-user systems where persistent background tasks for unprivileged users doesn’t make sense and is more indicative of a misbehaving program than a user trying to run a job. Oh my god the number of times we had to bounce systems because the unintended background processes of long gone users overloaded the system.
      - TA0x0 7y ago
        Sounds like you had junior admins at best leading your university's *NIX department. A mid-level admin in 1995 could have easily made a 100 line script to kill background processes from non-logged in users that were running over three hours (or whatever). systemd brought nothing to this arena.
        cycloptic 7y ago
        I don't understand this angle. You acknowledge the functionality could have been useful even 25 years ago; it makes perfect sense for a daemon developer to integrate the functionality into a session manager and put it behind a config flag which is exactly what they did.
        TA0x0 7y ago
        The functionality existed 25 years ago. systemd coming along and poorly implementing it provides nothing.
        cycloptic 7y ago
        If you already had that feature then you are free to use your 25-year-old solution instead of systemd.
  - Karunamon 7y ago
    My argument is remarkably simple. 1. Systemd did not solve any problems I actually had. 2. Systemd introduced problems that I did not have previously. 3. Systemd did not provide me any net benefit, that is, the few benefits it did provide over Upstart/SysV/etc. (easier service configuration and ordering) did not overshadow the issues it caused. Its introduction into my home and professional computing life has been a net negative.
    - CountSessine 7y ago
      Very narcissistic. If it’s so awful for you then don’t use it. But it solved a lot of other peoples problems, like rogue sessions on lab computers and broken executables that accidentally signal() themselves into orphan-hood because SIGHUP is truly one of the dumbest legacies of posix around, maybe just short of posix AIO. Seriously - don’t use it if you hate it so much.
      - Karunamon 7y ago
        Yes, my systems are primarily operated for my benefit. This should not be a controversial stance, and certainly not one worth hurling insults about. >Seriously - don’t use it if you hate it so much. Oh how I WISH that were a viable option. Few things would make me happier than that overcomplicated, opinionated, arrogant pile of unsafe code being excised viscera ex machnia from any system I have the misfortune of managing. Sadly I'm stuck with it if I want to run any mainstream Linux distros.
        CountSessine 7y ago
        Sadly I'm stuck with it if I want to run any mainstream Linux distros. Boohoo! Then man-up and look at all the alternatives out there! You can boot a Linux system with a simple 5-line shell script as /bin/init if you want! You clearly don’t care much about desktop Linux, because those of us that do don’t want a hundred rogue clipboard processes running in the background after we log out. Build a server box with Linux from scratch!
        cycloptic 7y ago
  - blibble 7y ago
    at university I remember working around the auto-killing of logged out users processes by running screen, then inside that screen ssh'ing into localhost
    - llarsson 7y ago
      Beautiful.
deleted 7y ago
[deleted]
detaro 7y ago
> The link you provide is absolutely huge The first message in the bugtracker already has the context of whats happening.
fao_ 7y ago
Maybe you should offer to move this bug report conversation somewhere more appropriate? It seems that this is better suited to a github issues thread
- dirtydroog 7y ago
  found the project manager!
ttctciyf 7y ago
To answer your question: remote login, start screen, ctl-A d (detach), log out, log back in, screen -r (resume) - there is no screen session because it was killed by systemd immediately after log out. (syslog entry: May 3 09:01:25 $HOSTNAME systemd[1]: session-6.scope: Killing process 3290 (screen) with signal SIGTERM. ) But that's hardly the point, the point is the toxic "you're doing it wrong" mentality that infests the systemd project and its adherents. I've run into this in so many ways since ceding defeat and allowing it onto my systems. This is just the latest in a long line of examples.
- cesarb 7y ago
  > remote login, start screen, ctl-A d (detach), log out, log back in, screen -r (resume) I just tried it on a fully up-to-date CentOS 8 box (which uses systemd), and it worked perfectly fine: after logging back in through ssh, `screen -r` restored the screen session as expected. From what I have read, that screen session would only be killed if I had set KillUserProcesses=yes on /etc/systemd/logind.conf, which is not the default.
  - deleted 7y ago
    [deleted]
  - ttctciyf 7y ago
    Switching to CentOS in order to use screen is not an appealing option, and the config appears not to work on my current distro (that might be my poor testing, but it's certainly not the default anyhow.) I understand Slackware still lacks systemd, so maybe that's a better choice for me :)
    - fsh 7y ago
      Please submit a bug report if the option doesn't work for you.
  - tyingq 7y ago
    It is the default. This behavior is controlled by the KillUserProcesses= setting in logind.conf, and the previous default of "no" is now changed to "yes". https://github.com/systemd/systemd/blob/2d4f8cf467b6825c91276808250823a29ab461fe/NEWS#L4356 https://github.com/systemd/systemd/blob/2d4f8cf467b6825c9127...
e12e 7y ago
See: https://www.pcworld.com/article/3078732/debian-and-fedora-users-are-debating-systemd-s-latest-controversial-change.html https://www.pcworld.com/article/3078732/debian-and-fedora-us... https://unix.stackexchange.com/questions/420594/why-process-killed-with-nohup https://unix.stackexchange.com/questions/420594/why-process-... https://askubuntu.com/questions/1169211/how-can-i-fix-nohup-byobu-tmux-screen-etc-to-not-die-when-i-disconnect-from https://askubuntu.com/questions/1169211/how-can-i-fix-nohup-...

throw0101a 7y ago

> Do you have decent examples of it failing to work? Poettering: > Note that in some cases it might be a good thing to kill screen sessions when the user otherwise logs out […] * https://lists.freedesktop.org/archives/systemd-devel/2011-June/002624.html https://lists.freedesktop.org/archives/systemd-devel/2011-Ju...

cmeacham98 7y ago
This is such a classic example of the type of argument I see from most anti-systemd proponents that it made me laugh out loud when I clicked your link. For the lazy, here's the context of that cherry-picked sentence: > In order not to break screen we currently do not set kill-user=1 or kill-session=1. > Note that in some cases it might be a good thing to kill screen sessions when the user otherwise logs out (think university, where students not logged in on a workstation should not be able to waste CPU), in other cases its a bad thing however (i.e. in yours). That means it must be configurable whether screen is considered an independent session or not.
- throw0101a 7y ago
  Translation: We broke long-standing POSIX/Unix behaviour of noHUP and think that's a good thing.
  - Spivak 7y ago
    I mean that is their position yes. It’s a good default too since it’s weird that “logging out” doesn’t imply “and end all my programs.” This is basically the same behavior as Windows where anything not going through the task scheduler ends when you log out. This is a feature that sysadmins have been asking for. On any multi-user system you run into this crap where background processes for users who are long-since gone just hang around forever because they do weird things or hang and ignored the signal. We implemented it ourselves with PAM but systemd’s solution is a lot cleaner. And they’re not breaking any POSIX behavior. Nowhere does it say when the system isn’t allowed to kill a process.
    - ycombobreaker 7y ago
      > it’s weird that “logging out” doesn’t imply “and end all my programs.” Weirdness is in the eye of the beholder. I regularly run programs whose lifecycles are not in sync with my login session. Why do I need to stick around to see a batch job complete? I can understand that different folks have different backgrounds which changes expectations... but come on... somebody bringing up tmux, screen, etc. should simply end the conversation. "Oh, that is a common and historical use case that I have not considered, today I learned something."
      - Supermancho 7y ago
        >> it’s weird that “logging out” doesn’t imply “and end all my programs.” > Weirdness is in the eye of the beholder It's a windows acolyte mindset. Many people don't imagine that a login is just another program, rather than the parent process.
        Spivak 7y ago
        Yes but that model conflicts with the human notion of being “logged in” to a system. And the current behavior is literally what you describe. It’s just the quirk of subreapers being implemented recently that daemonizing a process wasn’t local to your session. It makes zero sense that a process that double forks is reparented by init instead of your session leader. If how things worked currently was proposed today it would sound crazy.
  - deleted 7y ago
    [deleted]
- dooglius 7y ago
  Why exactly should students not be able to use CPU cycles while not logged in? I certainly did this as a student and would probably not have complained if it decided to kill my processes when doing so.
  - Spivak 7y ago
    You don’t deserve the downvotes. This is precisely the use-case this feature is good for. Multi-user systems where persistent background tasks for unprivileged users doesn’t make sense and is more indicative of a misbehaving program than a user trying to run a job. Oh my god the number of times we had to bounce systems because the unintended background processes of long gone users overloaded the system.
    - TA0x0 7y ago
      Sounds like you had junior admins at best leading your university's *NIX department. A mid-level admin in 1995 could have easily made a 100 line script to kill background processes from non-logged in users that were running over three hours (or whatever). systemd brought nothing to this arena.
      - cycloptic 7y ago
        I don't understand this angle. You acknowledge the functionality could have been useful even 25 years ago; it makes perfect sense for a daemon developer to integrate the functionality into a session manager and put it behind a config flag which is exactly what they did.
        TA0x0 7y ago
        The functionality existed 25 years ago. systemd coming along and poorly implementing it provides nothing.
        cycloptic 7y ago
        If you already had that feature then you are free to use your 25-year-old solution instead of systemd.
- Karunamon 7y ago
  My argument is remarkably simple. 1. Systemd did not solve any problems I actually had. 2. Systemd introduced problems that I did not have previously. 3. Systemd did not provide me any net benefit, that is, the few benefits it did provide over Upstart/SysV/etc. (easier service configuration and ordering) did not overshadow the issues it caused. Its introduction into my home and professional computing life has been a net negative.
  - CountSessine 7y ago
    Very narcissistic. If it’s so awful for you then don’t use it. But it solved a lot of other peoples problems, like rogue sessions on lab computers and broken executables that accidentally signal() themselves into orphan-hood because SIGHUP is truly one of the dumbest legacies of posix around, maybe just short of posix AIO. Seriously - don’t use it if you hate it so much.
    - Karunamon 7y ago
      Yes, my systems are primarily operated for my benefit. This should not be a controversial stance, and certainly not one worth hurling insults about. >Seriously - don’t use it if you hate it so much. Oh how I WISH that were a viable option. Few things would make me happier than that overcomplicated, opinionated, arrogant pile of unsafe code being excised viscera ex machnia from any system I have the misfortune of managing. Sadly I'm stuck with it if I want to run any mainstream Linux distros.
      - CountSessine 7y ago
        Sadly I'm stuck with it if I want to run any mainstream Linux distros. Boohoo! Then man-up and look at all the alternatives out there! You can boot a Linux system with a simple 5-line shell script as /bin/init if you want! You clearly don’t care much about desktop Linux, because those of us that do don’t want a hundred rogue clipboard processes running in the background after we log out. Build a server box with Linux from scratch!
      - cycloptic 7y ago
- blibble 7y ago
  at university I remember working around the auto-killing of logged out users processes by running screen, then inside that screen ssh'ing into localhost
  - llarsson 7y ago
    Beautiful.

deleted 7y ago

[deleted]

detaro 7y ago

> The link you provide is absolutely huge The first message in the bugtracker already has the context of whats happening.

fao_ 7y ago

Maybe you should offer to move this bug report conversation somewhere more appropriate? It seems that this is better suited to a github issues thread

dirtydroog 7y ago
found the project manager!

ttctciyf 7y ago

To answer your question: remote login, start screen, ctl-A d (detach), log out, log back in, screen -r (resume) - there is no screen session because it was killed by systemd immediately after log out. (syslog entry: May 3 09:01:25 $HOSTNAME systemd[1]: session-6.scope: Killing process 3290 (screen) with signal SIGTERM. ) But that's hardly the point, the point is the toxic "you're doing it wrong" mentality that infests the systemd project and its adherents. I've run into this in so many ways since ceding defeat and allowing it onto my systems. This is just the latest in a long line of examples.

cesarb 7y ago
> remote login, start screen, ctl-A d (detach), log out, log back in, screen -r (resume) I just tried it on a fully up-to-date CentOS 8 box (which uses systemd), and it worked perfectly fine: after logging back in through ssh, `screen -r` restored the screen session as expected. From what I have read, that screen session would only be killed if I had set KillUserProcesses=yes on /etc/systemd/logind.conf, which is not the default.
- deleted 7y ago
  [deleted]
- ttctciyf 7y ago
  Switching to CentOS in order to use screen is not an appealing option, and the config appears not to work on my current distro (that might be my poor testing, but it's certainly not the default anyhow.) I understand Slackware still lacks systemd, so maybe that's a better choice for me :)
  - fsh 7y ago
    Please submit a bug report if the option doesn't work for you.
- tyingq 7y ago
  It is the default. This behavior is controlled by the KillUserProcesses= setting in logind.conf, and the previous default of "no" is now changed to "yes". https://github.com/systemd/systemd/blob/2d4f8cf467b6825c91276808250823a29ab461fe/NEWS#L4356 https://github.com/systemd/systemd/blob/2d4f8cf467b6825c9127...

e12e 7y ago

See: https://www.pcworld.com/article/3078732/debian-and-fedora-users-are-debating-systemd-s-latest-controversial-change.html https://www.pcworld.com/article/3078732/debian-and-fedora-us... https://unix.stackexchange.com/questions/420594/why-process-killed-with-nohup https://unix.stackexchange.com/questions/420594/why-process-... https://askubuntu.com/questions/1169211/how-can-i-fix-nohup-byobu-tmux-screen-etc-to-not-die-when-i-disconnect-from https://askubuntu.com/questions/1169211/how-can-i-fix-nohup-...