7 ms·

This violates the rule of least surprise. Honestly, it looks like the Systemd maintainers operated without regards to the community at all. There's probably goi

This violates the rule of least surprise. Honestly, it looks like the Systemd maintainers operated without regards to the community at all. There's probably going to be some commenter who says "it only is surprising to you", but as evident by the email, it's surprising to a lot of users. Does anyone know if there's any precedent for a UNIX init system to behave like this? In my knowledge there isn't.

eeperson 10y ago
> Does anyone know if there's any precedent for a UNIX init system to behave like this? My guess is that previous init systems didn't do this because it wasn't really possible before cgroups. I'm certain that this behavior would be desired on multi-user systems to ensure that logged out users don't leave old processes lying around.
- 0x0 10y ago
  For that, couldn't any old shell script run from cron or whatever and kill any process tree not attached to a tty or X console?
  - eeperson 10y ago
    Wouldn't that kill off anything started by init as well?
  - pdkl95 10y ago
    I've seen that a few times over a decade ago on a couple multiuser boxen at a university. As you suggest, someone simply wrote a custom script that killed off jobs for a few reasons. It cause problems, of course, especially if you didn't now about the server's limitations. However, in that specific situation - A shared server with hundreds of active[1] sessions - it was justified. What I find strange about systemd tying processes to an active session is that was something that was only needed in multiuser situations. The systemd advocates (and others) keep telling me that Linux isn't really multiuser anymore as justification for various incompatible changes. In the case of single user desktop (including netbook, tablet, etc) systems there's no need to kill off processes. [1] if you count idling in Pine as "active"
    - digi_owl 10y ago
      Systemd is undergoing continual scope creep. It may have started as Poetterings way to handle some transient daemons on his laptop, but has since grown to cover containerized servers (hello CoreOS) and multiseat (effectively turning a single X86 computer into a desktop terminal server). I sometimes wonder if the systemd people encourage the confusion about what systemd really is about, so that they can shortcircuit any debate by claiming their opposition is misunderstanding and therefore not fit to comment.
AckSyn 10y ago
> the Systemd maintainers operated without regards to the community at all Don't act surprised. Those asshats stomped over a whole lot of shit and everyone acts like they're the savior of the init (and a dozen other) systems.
- toolz 10y ago
  Don't you feel like that's a little melodramatic? I mean they created open source software and forced exactly zero distro's or people to use it. I feel like every time I read about something with systemd someone is acting like there is a gun to their head to use it. If your distro of choice _chose_ to use systemd then your beef is with them forcing it on you...not systemd devs. They made an init system - your distro maintainers are the ones who decided it was the superior choice.
  - dingaling 10y ago
    systemd development is led by Red Hat, the $2 billion per annum gorilla in the corner. Third-party software, particularly from commercial vendors, typically uses Red Hat as the base system requirement. So you are correct, no-one holds a gun to distro maintainers' heads and forces systemd. They just find that there's no path forward without either [1] committing resources to keep abreast of the changes that systemd is creating both directly and indirectly or [2] just adopting systemd. Red Hat has won at this point through sheer persistence and clout, so most distros are going with option [2].
- gnoway 10y ago
  Certainly not everyone. There's a whole host of people who are angry about systemd the project primarily because of the (maybe misunderstood) behavior and communication from systemd the development team. Personally I don't see what everyone is so upset about here. As pointed out by message 15, they've simply changed the default behavior and provided a long-opt setting to restore the old behavior if required; the hundreds or thousands of people who don't closely follow systemd will just be inconvenienced temporarily until they figure out wtf is going on, then they are back in business. And, maybe next time they'll pay closer attention. Anyway I'm sure there will be a systemd-mux soon enough where you can declaratively define your long-running post-logout processes and register them via muxctl or some other existing sd-bus client.
wallacoloo 10y ago
> This violates the rule of least surprise. Maybe I'm completely misunderstanding things here, but when I log out, I expect all of my processes to be killed. When I'm logged off, and if another user logs on, it would be kind of weird if the system was still playing my music, etc, wouldn't it? If your processes don't die when you log off, then what exactly does it mean to "log off"? Or maybe the issue is that it's the init system doing this, rather than some other component?
- Nursie 10y ago
  No, if I background and nohup something, it ought to stay there until or unless I kill it or it exits. What it means to log off is to end the session you're in. A desktop session would end all the windows and systray-type stuff you're running, a terminal session would end the shell. but any processes you have explicitly daemonised or nohup'd should carry on. Maybe you have a headless linux box that you want to set some command-line music player playing on, why should you need to keep the terminal open to keep the music playing?
  - wallacoloo 10y ago
    > Maybe you have a headless linux box that you want to set some command-line music player playing on, why should you need to keep the terminal open to keep the music playing? If that behavior is desired, then it would make more sense to have the music player be a system service rather than a user service, in my opinion. As a non-user of nohup, it seems like a bizarre way to achieve the desired permanence. I guess maybe it was originally conceived as a way to run a long command from a terminal, but then effectively 'log out' of the terminal to prevent anyone else with physical access from running a command as you? Under graphical environments, this is solved via "locking" the computer. Under non-graphical environments, I would personally find something functionally equivalent to `my_command && exit` (but in a way that doesn't allow other people to ctrl+c and then steal your session) more intuitive - i.e. run the command and then log off, rather than "log off, but keep this command running". Or maybe I'm misunderstanding why things like `nohup` exist? In any case, I can agree that making significant breaking changes in this way is pretty irresponsible. But I'm still not sure it violates the rule of least surprise.
geofft 10y ago
> Does anyone know if there's any precedent for a UNIX init system to behave like this? I'm not sure if you'd call it an init system (but I guess any collection of shell scripts is a traditional UNIX init system), but MIT Athena has worked this way for many years: when you log out of a graphical session, there's an attempt to kill all your processes, because the machine should be fully for the use of whoever next logs in. Otherwise people would do long-running computing on machines in the computer labs ("clusters") and slow down interactive use for the next person -- and that's the non-malicious case. It used to be possible to get around this until some point in the late 2000s, when as part of unrelated rewriting, the logout script was set to just reboot the machine if it was unsure if it managed to clean everything up.
JdeBP 10y ago
There is, if six years of systemd having this counts as precedent. (-: The systemd people knew that this impacted the likes of screen and tmux, and there are discussions of this going back to 2010. Here's Jóhann B. Guðmundsson, erstwhile owner of the System 5 rc to systemd conversion project in Fedora, writing in July 2010, for example: * https://fedoraproject.org/w/index.php?title=User:Johannbg/QA/Systemd/Pam_systemd&oldid=187747#Options https://fedoraproject.org/w/index.php?title=User:Johannbg/QA...

eeperson 10y ago

> Does anyone know if there's any precedent for a UNIX init system to behave like this? My guess is that previous init systems didn't do this because it wasn't really possible before cgroups. I'm certain that this behavior would be desired on multi-user systems to ensure that logged out users don't leave old processes lying around.

0x0 10y ago
For that, couldn't any old shell script run from cron or whatever and kill any process tree not attached to a tty or X console?
- eeperson 10y ago
  Wouldn't that kill off anything started by init as well?
- pdkl95 10y ago
  I've seen that a few times over a decade ago on a couple multiuser boxen at a university. As you suggest, someone simply wrote a custom script that killed off jobs for a few reasons. It cause problems, of course, especially if you didn't now about the server's limitations. However, in that specific situation - A shared server with hundreds of active[1] sessions - it was justified. What I find strange about systemd tying processes to an active session is that was something that was only needed in multiuser situations. The systemd advocates (and others) keep telling me that Linux isn't really multiuser anymore as justification for various incompatible changes. In the case of single user desktop (including netbook, tablet, etc) systems there's no need to kill off processes. [1] if you count idling in Pine as "active"
  - digi_owl 10y ago
    Systemd is undergoing continual scope creep. It may have started as Poetterings way to handle some transient daemons on his laptop, but has since grown to cover containerized servers (hello CoreOS) and multiseat (effectively turning a single X86 computer into a desktop terminal server). I sometimes wonder if the systemd people encourage the confusion about what systemd really is about, so that they can shortcircuit any debate by claiming their opposition is misunderstanding and therefore not fit to comment.

AckSyn 10y ago

> the Systemd maintainers operated without regards to the community at all Don't act surprised. Those asshats stomped over a whole lot of shit and everyone acts like they're the savior of the init (and a dozen other) systems.

toolz 10y ago
Don't you feel like that's a little melodramatic? I mean they created open source software and forced exactly zero distro's or people to use it. I feel like every time I read about something with systemd someone is acting like there is a gun to their head to use it. If your distro of choice _chose_ to use systemd then your beef is with them forcing it on you...not systemd devs. They made an init system - your distro maintainers are the ones who decided it was the superior choice.
- dingaling 10y ago
  systemd development is led by Red Hat, the $2 billion per annum gorilla in the corner. Third-party software, particularly from commercial vendors, typically uses Red Hat as the base system requirement. So you are correct, no-one holds a gun to distro maintainers' heads and forces systemd. They just find that there's no path forward without either [1] committing resources to keep abreast of the changes that systemd is creating both directly and indirectly or [2] just adopting systemd. Red Hat has won at this point through sheer persistence and clout, so most distros are going with option [2].
gnoway 10y ago
Certainly not everyone. There's a whole host of people who are angry about systemd the project primarily because of the (maybe misunderstood) behavior and communication from systemd the development team. Personally I don't see what everyone is so upset about here. As pointed out by message 15, they've simply changed the default behavior and provided a long-opt setting to restore the old behavior if required; the hundreds or thousands of people who don't closely follow systemd will just be inconvenienced temporarily until they figure out wtf is going on, then they are back in business. And, maybe next time they'll pay closer attention. Anyway I'm sure there will be a systemd-mux soon enough where you can declaratively define your long-running post-logout processes and register them via muxctl or some other existing sd-bus client.

wallacoloo 10y ago

> This violates the rule of least surprise. Maybe I'm completely misunderstanding things here, but when I log out, I expect all of my processes to be killed. When I'm logged off, and if another user logs on, it would be kind of weird if the system was still playing my music, etc, wouldn't it? If your processes don't die when you log off, then what exactly does it mean to "log off"? Or maybe the issue is that it's the init system doing this, rather than some other component?

Nursie 10y ago
No, if I background and nohup something, it ought to stay there until or unless I kill it or it exits. What it means to log off is to end the session you're in. A desktop session would end all the windows and systray-type stuff you're running, a terminal session would end the shell. but any processes you have explicitly daemonised or nohup'd should carry on. Maybe you have a headless linux box that you want to set some command-line music player playing on, why should you need to keep the terminal open to keep the music playing?
- wallacoloo 10y ago
  > Maybe you have a headless linux box that you want to set some command-line music player playing on, why should you need to keep the terminal open to keep the music playing? If that behavior is desired, then it would make more sense to have the music player be a system service rather than a user service, in my opinion. As a non-user of nohup, it seems like a bizarre way to achieve the desired permanence. I guess maybe it was originally conceived as a way to run a long command from a terminal, but then effectively 'log out' of the terminal to prevent anyone else with physical access from running a command as you? Under graphical environments, this is solved via "locking" the computer. Under non-graphical environments, I would personally find something functionally equivalent to `my_command && exit` (but in a way that doesn't allow other people to ctrl+c and then steal your session) more intuitive - i.e. run the command and then log off, rather than "log off, but keep this command running". Or maybe I'm misunderstanding why things like `nohup` exist? In any case, I can agree that making significant breaking changes in this way is pretty irresponsible. But I'm still not sure it violates the rule of least surprise.

geofft 10y ago

> Does anyone know if there's any precedent for a UNIX init system to behave like this? I'm not sure if you'd call it an init system (but I guess any collection of shell scripts is a traditional UNIX init system), but MIT Athena has worked this way for many years: when you log out of a graphical session, there's an attempt to kill all your processes, because the machine should be fully for the use of whoever next logs in. Otherwise people would do long-running computing on machines in the computer labs ("clusters") and slow down interactive use for the next person -- and that's the non-malicious case. It used to be possible to get around this until some point in the late 2000s, when as part of unrelated rewriting, the logout script was set to just reboot the machine if it was unsure if it managed to clean everything up.

JdeBP 10y ago

There is, if six years of systemd having this counts as precedent. (-: The systemd people knew that this impacted the likes of screen and tmux, and there are discussions of this going back to 2010. Here's Jóhann B. Guðmundsson, erstwhile owner of the System 5 rc to systemd conversion project in Fedora, writing in July 2010, for example: * https://fedoraproject.org/w/index.php?title=User:Johannbg/QA/Systemd/Pam_systemd&oldid=187747#Options https://fedoraproject.org/w/index.php?title=User:Johannbg/QA...