Slashdot Mirror

← Back to Stories (view on slashdot.org)

Systemd Starts Killing Your Background Processes By Default (blog.fefe.de)

Posted by EditorDavid on from the features-not-bugs dept.

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."

13 of 924 comments (clear)

  1. WTF by BlackPignouf · · Score: 5, Interesting

    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.

    1. Re:WTF by Kernel+Kurtz · · Score: 3, Interesting

      It requires running screen via a special invocation, or modifying screen to be aware of systemd APIs.

      WTF should screen care about systemd?

      Seriously....

    2. Re:WTF by RightwingNutjob · · Score: 3, Interesting

      Best practice is to do what the users says and not to try to make the machine attempt to be smarter than him. If he wants to run something with nohup, he'll use nohup. If he wants to run something with screen, he'll use screen. That's what those commands are for.

      If a program fucks up and is unresponsive, the correct course of action is not to paper over it with your whiz-bang init system/session manager/ninja/pirate/robot/zombie; the correct course of action is to 1) identify the problem (which you can't do if the process is clobbered automatically) and 2) fix it or file a bug.

  2. Re:I assumed this was already a default by Anonymous Coward · · Score: 5, Interesting

    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?

  3. Re:I assumed this was already a default by sjames · · Score: 5, Interesting

    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.

  4. It's all Gnome's fault by the_B0fh · · Score: 5, Interesting

    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?!

    1. Re:It's all Gnome's fault by mvdwege · · Score: 2, Interesting

      No, Gnome is just the most obvious offender. But the problem exists; notwithstanding how handy things like screen are, to the system (and by extension, to the admin), a long running detached process is indistinguishable from a program that did not cleanly exit. In order to make that distinction, manual intervention is necessary.

      The systemd devs just decided to default to kill 'em all in absence of intervention, mostly because with systemd admins finally have the tools to properly separate these kinds of processes into their own resource managed partitions, using cgroups.

      I can see the logic. I can see why the change in default behaviour might be a bit disconcerting, but the sheer amount of hateful bile being spewed is absolutely not warranted, and in fact drives the undecided into the systemd camp.

      The old ways were not perfect, despite all attempts by script kiddies in their momma's basement who pretend to be admins on Slashdot to convince us otherwise.

      --
      "I know I will be modded down for this": where's the option '-1, Asking for it'?
  5. Re:I assumed this was already a default by sjames · · Score: 4, Interesting

    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.

  6. Pure Insanity by somenickname · · Score: 5, Interesting

    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?

  7. Re:security best practice? by Anonymous Coward · · Score: 2, Interesting

    tmux.

    How are you supposed to run tmux if systemd goes killing background processes when you logout?

  8. Re:I assumed this was already a default by Anonymous Coward · · Score: 2, Interesting

    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.

  9. Re:security best practice? by Anonymous Coward · · Score: 5, Interesting

    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.

  10. One simple rule by Damouze · · Score: 3, Interesting

    Don't use systemd. It violates the very core philosophy of Unix.

    --
    And on the Eighth Day, Man created God.