7 ms·

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

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.
  - sethammons 7y ago
    ”ain't no rule says a dog can't play basketball”
  - dooglius 7y ago
    >It’s a good default too since it’s weird that “logging out” doesn’t imply “and end all my programs.” I have to disagree, I don't think I've ever run something where what I intend is "kill this mid-run if my connection drops". >This is basically the same behavior as Windows My recollection from when I used Windows Server (admittedly some time ago) is that the default behavior on connection loss or closing an RDP window is indeed the tmux-like behavior. The user has to click a separate "Log out" button, and even then, has to manually confirm that it's okay to kill anything left running.
  - throw0101a 7y ago
    > It’s a good default too since it’s weird that “logging out” doesn’t imply “and end all my programs.” It may be a good default if you're starting from scratch, but GNU Screen has came out in 1987. (Poettering was 7 years old then.) > This is basically the same behavior as Windows […] Comparing it to Windows' behaviour is not going to win you any positive points with me. :) > This is a feature that sysadmins have been asking for. As a sysadmin this breaks my own daily workflow. I have 400 VMs that are treated as pets and I probably screen sessions on at least a third of them. (I have another 500 that are cattle-like.) > And they’re not breaking any POSIX behavior. Nowhere does it say when the system isn’t allowed to kill a process. Aka, malicious compliance. See also: nowhere does it say that the US President cannot fire the FBI Director. Also: nowhere does it say that the US Senate has to hold hearings when a US President nominates a judge for the US Supreme Court.
  - magicalhippo 7y ago
    > This is basically the same behavior as Windows where anything not going through the task scheduler ends when you log out. But when using remote connections, ie RDP, the default is that your session is disconnected. You have to actively choose to log out of an RDP session. When using SSH I typically want the same. If I put my laptop to sleep or a networking issue causes the TCP connection to end, I want my terminal session to be restored when I reconnect via SSH.
- 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.

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.
- sethammons 7y ago
  ”ain't no rule says a dog can't play basketball”
- dooglius 7y ago
  >It’s a good default too since it’s weird that “logging out” doesn’t imply “and end all my programs.” I have to disagree, I don't think I've ever run something where what I intend is "kill this mid-run if my connection drops". >This is basically the same behavior as Windows My recollection from when I used Windows Server (admittedly some time ago) is that the default behavior on connection loss or closing an RDP window is indeed the tmux-like behavior. The user has to click a separate "Log out" button, and even then, has to manually confirm that it's okay to kill anything left running.
- throw0101a 7y ago
  > It’s a good default too since it’s weird that “logging out” doesn’t imply “and end all my programs.” It may be a good default if you're starting from scratch, but GNU Screen has came out in 1987. (Poettering was 7 years old then.) > This is basically the same behavior as Windows […] Comparing it to Windows' behaviour is not going to win you any positive points with me. :) > This is a feature that sysadmins have been asking for. As a sysadmin this breaks my own daily workflow. I have 400 VMs that are treated as pets and I probably screen sessions on at least a third of them. (I have another 500 that are cattle-like.) > And they’re not breaking any POSIX behavior. Nowhere does it say when the system isn’t allowed to kill a process. Aka, malicious compliance. See also: nowhere does it say that the US President cannot fire the FBI Director. Also: nowhere does it say that the US Senate has to hold hearings when a US President nominates a judge for the US Supreme Court.
- magicalhippo 7y ago
  > This is basically the same behavior as Windows where anything not going through the task scheduler ends when you log out. But when using remote connections, ie RDP, the default is that your session is disconnected. You have to actively choose to log out of an RDP session. When using SSH I typically want the same. If I put my laptop to sleep or a networking issue causes the TCP connection to end, I want my terminal session to be restored when I reconnect via SSH.
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.