3 ms·

> 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

> 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.

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.