My frustration with systemd is that it creeps out over time into other functionality, and that it's difficult to find the right documentation.
Like when logind was changed to kill background processes when you log out, by making KillUserProcesses=yes the default. Some Linux distros left that as is, others overrode it in /etc/systemd/logind.conf. So, figuring out what was happening, and how to fix it, was confusing. I had no idea it would have been logind doing that.
Similar for changes introduced with systemd-resolved.
In particular, "background processes" includes screen/tmux sessions that you started. This change completely broke the largest reason that people use screen or tmux.
Not sure if sarcastic, but the systemd default makes sense. Why should random processes linger in a background, with an ill defined “not answering a signal” hack? There is no distinction between a frozen process and tmux. They can easily register a user service and continue running there.
It wasn't respecting things that have been considered normal for a while. Even calling setsid(), which tmux does, didn't save it from being killed. Same for nohup.
When the systemd people say session, they mean you would have to specifically do some kind of dbus call I'm not familiar with.
Are you seriously claiming that processes ignoring or handling signals rather than dying is an ill defined hack? That's a well defined, long established, normal way of doing things on UNIX and Linux systems. Also, that really isn't a good way of detecting frozen processes, since in your world, the only answers you'd ever get are "it's frozen" or "it wasn't frozen and now it's dead".
> They can easily register a user service and continue running there.
So systemd came in and broke the 50-year-old way of doing things, and now the programs that got broken should all have to add systemd-specific code to work again?
> Are you seriously claiming that processes ignoring or handling signals rather than dying is an ill defined hack?
Yes. Just because it is 50-years-old doesn’t make it suddenly a valid approach. There are 4 states here - process running with usual semantics for closing, process running that would like to linger in the background, and the frozen version of this two. How should a service manager/resource handle — that is very much in-scope for systemd differentiate between a frozen process that should very much be cleaned up in the no-linger case, and any process wanting to linger? And there are well-established ways to determine whether a process is frozen — pinging it expecting a specific answer.
Systemd differentiates between no-linger/linger by introducing user services - one should only write a trivial alias/wrapper script for tmux and can continue to use it to their liking. Also, it has a compile time flag, as well as a runtime config one - it is up to the distro or the user to revert back to the old way.
Wow, are people seriously still fussing about this? Systemd made the call to use a more secure default, they should be applauded for it. People who want the insecure way to be the default should take it up with their distro.
How is killing processes when the user "logs out" at all good for security? If the processes were malicious or vulnerable, they could have done their damage or been exploited while the user was still logged in.
You don't think malicious code could wait for certain specific times to trigger, rather than running immediately during an active login session where it could be traced back to?
Like when logind was changed to kill background processes when you log out, by making KillUserProcesses=yes the default. Some Linux distros left that as is, others overrode it in /etc/systemd/logind.conf. So, figuring out what was happening, and how to fix it, was confusing. I had no idea it would have been logind doing that.
Similar for changes introduced with systemd-resolved.