Distributors ponder a systemd change

Posted Jun 10, 2016 17:49 UTC (Fri) by matthias (subscriber, #94967)
In reply to: Distributors ponder a systemd change by azumanga
Parent article: Distributors ponder a systemd change

Simply not true. Every process doing file IO should intercept SIGHUP to ensure not terminating in the middle of some IO and producing garbage. If such a process freezes for some reason, the normal way of terminating will not work and the process is waiting to be SIGKILLed, either by the user, at session end or during shutdown. I have seen such processes. SIGHUP is simply a signal saying please terminate, your session has ended. Up to now session management was assuming that this always works. With this change systemd will clean up processes where this did not work.

Which processes do you have in mind that would be changed? Obviously tmux and screen. Anything else? Processes that are actually daemons do not count (they are out of scope anyway as they do not belong to the session). Neither do processes count that are explicitly backgrounded by the user. For these processes the user will make sure that session management does not kill them (starting with a wrapper like systemd-run).

Distributors ponder a systemd change

Posted Jun 10, 2016 18:05 UTC (Fri) by viro (subscriber, #7872) [Link]

... assuming they knew they'll need these processes to outlive the session back when they were starting said processes. Unfortunately, the situations when it's not true tend to be of the "lots of time already went into computation and kill&restart the right way is very unappealing" variety.

Distributors ponder a systemd change

Posted Jun 11, 2016 10:53 UTC (Sat) by ras (subscriber, #33059) [Link]

> Simply not true. Every process doing file IO should intercept SIGHUP to ensure not terminating in the middle of some IO and producing garbage. If such a process freezes for some reason, the normal way of terminating will not work and the process is waiting to be SIGKILLed, either by the user, at session end or during shutdown. I have seen such processes. SIGHUP is simply a signal saying please terminate, your session has ended. Up to now session management was assuming that this always works.

All accurate.

> With this change systemd will clean up processes where this did not work.

Sadly systemd isn't physic and so can't currently distinguish between when it didn't work and when it didn't matter. But as you observe, there are only a few known programs this effects. So they could be patched. And I willing to concede the inhouse broken by this change don't matter. Thats seems to be business as usual open source - I get screwed over by non-backward API changes on a fairly regular basis.

But this always cleaning up processes where "it didn't work": not a good idea. The default should be not hide the problem. Just in case you don't know: "didn't work" is bad thing. It's caused by a bug. It is better for all of us if we get that bug fixed ASAP. If processes hanging around caused most of us a lot of pain, then maybe you would have point. But we lived with it for 30 years, so the pain can't be that great.

Nonetheless as you have pointed out most is not all, and in particular this behaviour has caused you real pain. Fair enough. I hope nobody would argue with it providing a solution for you and anybody else that has it.

My issue: that solution has existed for 15 years.