3 ms·
> So you were always able to change the config to restore the previous behavior from the moment the default turned it on. No, you were not. The thing that peo
by JdeBP 8y ago
> So you were always able to change the config to restore the previous behavior from the moment the default turned it on.
No, you were not.
The thing that people are missing here is that neither of the systemd-logind behaviours, with KillUserProcesses=yes or KillUserProcesses=no, is the long-standing behaviour of kernel login sessions all of the way back to 7th Edition that nohup, tmux, screen, emacs --daemon, mosh-server, deluged, and more all interoperate with.
The behaviour of kernel login sessions is that end of login session is a HUP signal to the session leader, and that termination of the entire TTY login service (such as at system shutdown) is a TERM signal to everything followed by a KILL signal to everything then remaining.
The systemd-logind session behaviour with KillUserProcesses=no is no signals at all at the end of the login session, and at termination of the TTY login service both HUP and TERM signals together then KILL signals, to everything.
The systemd-logind session behaviour with KillUserProcesses=yes is both HUP and TERM signals together then KILL signals, to everything, both at login session termination and at TTY login service stop.
As I pointed out years ago, the fix is to make systemd-logind use KillUnit at hangup and StopUnit at service termination, actually providing the conventional behaviour which it currently does not in any mode and addressing the original problems (with some background GNOME utilities in a login session that were never being sent a HUP signal at logout and would have exited had they been) that motivated this whole mechanism in the first place.
* https://news.ycombinator.com/item?id=12335128 https://news.ycombinator.com/item?id=12335128
* https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=825394#221 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=825394#221
* https://news.ycombinator.com/item?id=11798604 https://news.ycombinator.com/item?id=11798604