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."
So, "screen" has always been a good way to ensure that processes don't get killed randomly by disconnections, logout or X crashes.
Then comes systemd and kills all your processes at logout, even when launched with screen.
Finally, then comes Poettering, explaining you that you're a moron if you expect to keep those processes running.
Seriously, the systemd devs make it really hard no to hate them.
Wouldn't it be better to save state on logout and restore on login? This would provide the balance between saving system resources and allowing a user to start off where they left off. Of course applications would need to be aware of state saving. Is there already some sort of API for this?
Jumpstart the tartan drive.
What about when I have a long running process I need to run and I don't want it to be stopped if I get disconnected from wifi? Or maybe I know it'll still be running when I have to go home?
The way it is now, if I just disconnect from ssh, they get killed. If i go out of my way to ensure they won't (e.g. start them in a screen session) then they aren't. How is the old way a problem?
No, it wouldn't be. First, if you will contemplate what is involved in saving state, you'll realize what an incredible challenge it would be to do so perfectly every time in every case.
For example, if I start a slow FTP session, how will the magic state saver cope? Remember, the remote server is not taking part in the state saving.
Second, had you done that, wouldn't you be a bit disappointed to find out 24 hours later that the file transfer has made no progress at all?
Screen, nohup, and friends exist explicitly to allow a terminal session to dettach and re-attach as needed. I use screen all the time, especially where a firewall might time out.
It's probably best for the system to work like it's always worked. If they want Potterix to work differently, they should put out a distro.
Apparently, according to some reports, this came about because Gnome can't properly kill off all your sub processes when you log out.
So, systemd to the rescue. Why is anyone using gnome again?!
Do that all you want on a desktop. On a server, perhaps nobody cares or perhaps the admin will kill your processes. Keep in mind, if you don't actually touch the pages your allocation only exists in theory. If you do, it'll get swapped out if you don't keep touching it periodically.
Once it becomes obvious you're burning resources for fun, the admin will either drop your ulimits down or terminate access.
I run a few systems where the user is expected to start simulations that may run for weeks. I don't need something to start mysteriously killing those processes off.
The real problem is that there is no good alternative. The old init systems are creaking under the weight of many patches, scripts and hacks. Even the BSDs are looking for a good replacement to their old systems. systemd is just the best of a bad bunch, and to be fair it does provide solutions to a number of issues.
The only way to combat systemd is to build something better. Fork it, or just start from scratch, but offer something that fixes the issues that systemd addresses, particularly the prior lack of common APIs for many seemingly simple management tasks.
const int one = 65536; (Silvermoon, Texture.cs)
SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
Changes like this make me wonder if the systemd developers even use Linux beyond their local development workstations. This isn't just an inconvenient change, it breaks the expected and decades old behavior of how Unix machines work. This breaks ^Z/bg/disown, it breaks screen, it breaks nohup, etc. Yes, these things can be made to work still but, why do I need to jump through hoops to re-gain the functionality I've relied on for decades? If I'm not aware of this change, how would I even figure out why all my screen sessions died when I logged out? What benefits am I gaining by having this be the default behavior?
tmux.
How are you supposed to run tmux if systemd goes killing background processes when you logout?
That isn't a problem of course, even with the new systemd defaults. Just use systemd-run --user --scope screen and the process and all other processes started from screen will survive logout.
Do you really think that's a reasonable answer to the question of why systemd had to break things like nohup and screen?
You don't make gratuitous changes to systems that fundamentally alter how the system works and break common utilities in the process.
If you'd get Poettering's cock out of your mouth for ten seconds you might realize this.
For me, it's not so much the poor quality; it's the poor quality, the arrogant/wontfix response to bugs, the 'adapt to us' attitude, the strawmen arguments, the ties to GNOME (quickly becoming its own shitheap), the idiotic assumptions and bad practices that throw out decades of learning and experience...and the fact that, despite all this, it's still being adopted.
Don't use systemd. It violates the very core philosophy of Unix.
And on the Eighth Day, Man created God.