Slashdot Mirror
Systemd Starts Killing Your Background Processes By Default (blog.fefe.de)
New submitter nautsch writes: systemd changed a default value in logind.conf to "yes", which will kill all your processes, when you log out... There is already a bug-report over at debian: Debian bug tracker.
The new change means "user sessions will be properly cleaned up after," according to the changelog, "but additional steps are necessary to allow intentionally long-running processes to survive logout. To effectively allow users to run long-term tasks even if they are logged out, lingering must be enabled for them."
The new change means "user sessions will be properly cleaned up after," according to the changelog, "but additional steps are necessary to allow intentionally long-running processes to survive logout. To effectively allow users to run long-term tasks even if they are logged out, lingering must be enabled for them."
Or you know use Slackware... it's the oldest Linux Distro and does not use systemd.
Do not look at laser with remaining good eye.
you should explicitly state so
nohup
"it should rather be disabled .. by setting KillUserProcesses=no in /etc/systemd/logind.conf ." ref
And nohup up is what systemd is breaking in this "update" ... do try to keep up.
How about doing anything that takes a long time and you don't want to remain logged in for it to complete? For example you are running a standard program that is going to take hours or even days to process some data, so you redirect stdin to /dev/null, stdout to one file, stderr to either the same file or another file, and you start the whole thing with the nohup shell command.
There is already a well established mechanism for cleaning up background processes, i.e. the SIGHUP signal. And there is already a mechanism for explicitly stating that you don't want a process to die when you log out, and that is the shell's "nohup" command (which blocks the hangup signal that is sent to the process when the user exits).
And in what way does this new mechanism "enhance security"? Running something in the background after you log out doesn't give you any more privileges than if you remained logged in.
Why do the systemd folks think they need to keep reinventing the wheel? This feels like a solution in search of a problem.
FWIW, I've only found one quote by Lennart Poettering about the entire thing (source):
I am not sure I follow. Note that user@.service is already reference counted by the login sessions around. i.e. it is started before the first user session of a specific user is created, and stopped when the last user session ends. I don't follow why that behaviour is not sufficient?
Lennart seems to have learned by now to be careful what he says in public, so I don't expect him to call anyone a moron here.
No, there's a similar debate blowing up on the Fedora list as well, it's just that there's hardly anyone left with the energy to fight the cabal any more.
From the Fedora List:
Hire a Linux system administrator, systems engineer,
While "clean up after yourself" is generally a good idea (ask your mom!), in this case it is going to cause a lot of problems because it is being enforced from above in ways that will have unintended consequences because the enforcement mechanism doesn't understand context. I am sure that screen/tmux aren't the only tools affected.
Heck, I implicitly rely on persistence of background processes myself on a semi-regular basis. Doing something that runs counter to this expectation is going to break random stuff, and result in a lot of pissed off sysadmins. This behavior arguably makes sense for desktop distros, but given that Debian is primarily a server distro it should not be the default. Let downstream desktop distros like Ubuntu/Mint/etc. modify the default behavior, if they deem it appropriate (it doesn't even require a code change, it is a config option).
It is also symptomatic of the "all bow down before systemd" mentality, and I have a big problem with that. They may have good intentions, but there are some serious issues with how they're going about implementing their vision.
That already happens. The user shell knows that the user has disconnected via HUP signal, and then passes that signal along to the spawned child processes. If the user ran a process with & or nohup, then the shell knows not to mess with those processes. That is, until systemd comes along, breaks more convention, and just terminates everything anyway, ignoring what the user already told the system. Unless the user specifically interacts in such a way that only works on certain systemd supported operating system variants, running certain versions of systemd, configured in certain specific ways.
The previous and well understood behavior already did this, and it worked on all UNIX-like systems. The new systemd way works on a very small minority of systems, and requires special behavior and a half-dozen special checks to detect environment.
This is not an improvement. This is single-user proprietary behavior.