Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?
Debian Operating Systems

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

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."
This discussion has been archived. No new comments can be posted.

Systemd Starts Killing Your Background Processes By Default

Comments Filter:
  • by Anonymous Coward on Sunday May 29, 2016 @05:39PM (#52207037)

    In my mind if you want background processes to stay alive, you should explicitly state so, and not have the system make the assumption, even if it has been the convention that background processes do stay alive. To me it just seems a potential vector for a backdoor or something, I dunno >

    • by Anonymous Coward on Sunday May 29, 2016 @06:13PM (#52207295)

      you should explicitly state so


      • by Archfeld ( 6757 ) <treboreel@live.com> on Sunday May 29, 2016 @07:36PM (#52207725) Journal

        Not sure why the GP was marked as troll, it stated the problem very clearly, and the parent of this, nohup response is a very good, perhaps best response. You should NOT leave user processes active post logout unless they are specifically declared as such, and even then there is room for argument that allowing a USER , not admin level process to run in absence of the user is bad practice.

        • by drinkypoo ( 153816 ) <martin.espinoza@gmail.com> on Sunday May 29, 2016 @08:59PM (#52208095) Homepage Journal

          Not sure why the GP was marked as troll, it stated the problem very clearly, and the parent of this, nohup response is a very good, perhaps best response. You should NOT leave user processes active post logout unless they are specifically declared as such,

          Here's the problem with your idea. These processes are already killed when you log out if you haven't done something to detach them from their PPID. That's already the default. Now the problem is that systemd will kill even processes you have done that to, unless you reconfigure systemd. That is not arduous, but changing the default behavior should not be the default. I am Jack's total lack of surprise that the systemd developers would change default behavior, since that's what they have been up to all along. I am also unsurprised that many slashdotters who lack perspective are willing to share their utterly worthless opinions with the rest of us. It's not that these guys are trying to make improvements that rankles. It's the slipshod quality of their efforts, and their arrogant insistence that they know better than the giants of computing history that figured this stuff out to begin with. They put together an extremely compelling system that we are still using, knocking off, and reinventing decades later, and these systemd tools are sure that they were a bunch of morons.

          • by Anonymous Coward on Sunday May 29, 2016 @11:30PM (#52208719)
            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.
        • by l3v1 ( 787564 ) on Monday May 30, 2016 @01:17AM (#52209041)
          Well, maybe because if you read the linked thread you'd see that screen/tmux/nohup/etc. are all affected by this idiotic change. Never liked the systemd philosophy, and their attitude even less, and such changes certainly won't make me like them.
        • by MrKaos ( 858439 ) on Monday May 30, 2016 @02:27AM (#52209191) Journal

          Not sure why the GP was marked as troll, it stated the problem very clearly, and the parent of this, nohup response is a very good, perhaps best response.


          You should NOT leave user processes active post logout unless they are specifically declared as such,

          nohup someProcess &

          the ampersand *is* the specific declaration that you want the process to be active post logout, otherwise it does not survive the termination of the login session.

          and even then there is room for argument that allowing a USER , not admin level process to run in absence of the user is bad practice.

          Not at all. I have processes to run that are processing information when I leave to go home and I want to check it the next day when it has finished. If I did not have that option then my user session would have to remain logged in and that *is* recognized as bad security practice.

      • Or CTRL-Z / bg / disown if you forgot the nohup &
    • There seem only a few reasons a user process should stick around, or even start, after a user has logged out. 1) Cron.. Nuff said, 2) Screen - detached process, to be re-attached later 3) VNC - glorified Screen with a whole host of Window manager baggage 4) Inelegantly interrupted shell session that leaves a dead process 5) At jobs (ok.. like cron, but different) .. hmm those come to mind ... any others? In systemds defense, if its main objective is to manage Init... this seems appropriate, but.. it shoul
      • by jsm300 ( 669719 ) on Monday May 30, 2016 @01:43AM (#52209101)

        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.

  • by QuietLagoon ( 813062 ) on Sunday May 29, 2016 @05:39PM (#52207039)
    Better feed it [youtube.com]. :)
  • by msauve ( 701917 ) on Sunday May 29, 2016 @05:43PM (#52207059)
    "user sessions will be properly and improperly cleaned up after..."

  • by Anonymous Coward on Sunday May 29, 2016 @05:48PM (#52207097)

    Yay! Awesome!

    systemd is by far the stupidest thing to happen to Linux, ever... It's not that different from Java. "Oh, new clean shiny thing that is lean and mean!" Then they halfheartedly learn what the real world requires and half-ass it ever since.

  • WTF (Score:5, Interesting)

    by BlackPignouf ( 1017012 ) on Sunday May 29, 2016 @05:49PM (#52207109)

    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.

    • Re:WTF (Score:5, Insightful)

      by AmiMoJo ( 196126 ) <mojo@nOspAm.world3.net> on Sunday May 29, 2016 @06:16PM (#52207311) Homepage Journal

      Poettering said nothing of the sort, you just assumed he did as kind of reflexive ad-hominem. systemd seems to be a common trigger word on Slashdot these days.

      The problem here is that the mechanism supplied for handling this situation is inadequate. It requires running screen via a special invocation, or modifying screen to be aware of systemd APIs. So Poettering isn't calling anyone a moron for wanting this functionality, he is offering an API for it. It's just that the API is not good enough, which does bring the systemd developer's competence into question.

      There is plenty to be bothered by here, but there is no need to drag it down to that level.

      • Re:WTF (Score:4, Interesting)

        by Kernel Kurtz ( 182424 ) on Sunday May 29, 2016 @08:45PM (#52208031) Homepage

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

        WTF should screen care about systemd?


  • by Noryungi ( 70322 ) on Sunday May 29, 2016 @05:54PM (#52207145) Homepage Journal

    Fear not, people of Slashdot, because there is an option to maintain background processes, even after user disconnection.

    But this option is not "on" by default. So, yeah, screen and tmux all of a sudden become useless, unless you fiddle with the knobs.

    Seriously, now, fsck systemd: Slackware and OpenBSD for me from now on.

    Even Mac OS X has the decency not to mess up your tmux sessions when suspending and restoring your session. Fsck systemd.

  • by epine ( 68316 ) on Sunday May 29, 2016 @06:14PM (#52207301)

    This story: Systemd Starts Killing Your Background Processes By Default

    Previous story: Massive Backlash Building Over Windows 10 Upgrades

    That's the best conjunction of two headlines that I've noticed in my many years here.

    FWIW, I'm a happy PC-BSD user, not that this is a panacea by any means, but there does seem to be less of the "stupidity on a rampage" form of collateral damage.

    I pay the price with a lot more "W?TF doesn't Firefox play this media type either?" and I find I have to page bounce to Chrome once or twice almost every day (my FF is plug-in central, my Chrome is naked install).

    Unfortunately, I can't even brag that PC-BSD is a successful Poettering removal tool, as I still had to fight some nasty battles with PulseAudio due to rampant ecosystem taint in the package tree that PC-BSD doesn't have the resources to strip out (nor, sadly, does the entire *BSD Avenger collective). Get this, the GUI control I needed to mess with only appears if certain PulseAudio processes are active, but because of my debugging mode, those processes were timing out before I could visit all the places where I thought the GUI control might possibly show up (discoverability anti-pattern in anti-flagrante delicto).

    Every large software ecosystem must eventually manage breakage. There are good ways to go about this, and there are bad ways to go about this, and then there are Poettering ways to go about this. It's the added ego problem that seems excessive.

  • by the_B0fh ( 208483 ) on Sunday May 29, 2016 @06:50PM (#52207491) Homepage

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

    • That's my take on it as well. Basically, poorly written stuff like PulseAudio doesn't properly shut down when you log off. The solution, obviously, is to break the normal behavior of Linux so that some moronic sound daemon properly shuts down when you log out. It's like watching a train wreck in slow motion.

    • by JohnFen ( 1641097 ) on Sunday May 29, 2016 @09:08PM (#52208143)

      It sure looks that way. If that's actually the case, then I am at a loss for words. The amount of bad judgment required to resolve a Gnome bug by modifying the behavior of the OS is stunning.

      • I'm guessing that there's been tens, if not hundreds, of userspace bugs that Microsoft has fixed in the kernel. Bugs in the Start Menu, Aero, Metro, File Explorer, and so on. Arguably one of the biggest mistakes was having the font driver so deeply in the kernel, making it susceptible to vulnerabilities that have received patch after patch in the last year. (Oh, and Adobe worked with Microsoft on that part. Yay.)

        Consider what this says about modern userspace Linux development: despite working in "the baz

    • Re: (Score:3, Interesting)

      by mvdwege ( 243851 )

      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 pro

      • by iwbcman ( 603788 ) on Monday May 30, 2016 @08:15AM (#52210033) Homepage

        Despite all the hate I still appreciate what systemd is attempting to do. Now I am not perfectly happy with all the design decisions made in systemd, sometimes grokking new ways of doing things takes a while and I have yet to master all of it. But sometimes I feel like Poettering has been working away at my unpublished list of broken things regarding init.d. I use to be an LTSP server admin at a German university. 400 users via 30 ancient pc's(timeframe was 2004-2008, pc's were 1996-2000 era), running off of one dual-cpu AMD athlon server. Hunting down rogue processes that failed to exit properly was one of the ongoing thorns in my side as an admin. The init system, replete with the run level system, has beek broken in Linux land basically since forever. It was never a matter of which distro you used, they all had problems. There may have been better ways to solve some of these problems, but in contrast to all the fake screaming and cryin you read on slashdot, Poettering, along with several others, attempted to finally do something about it, and even worse damn near every linux distro switched to systemd when systemd was undoubtedly still in it's infancy(this thing, even though it's a baby, has already kicked every other competing init system to the curb, unfinished, with warts and all, it trounces what we had).

        I fully suspect to feel the same way about systemd that I felt about pulseaudio: at first pulseaudio was a pain, it was not very reliable and rather pflagmatic at times, involving lots of arcane configuration incantations. However as time went it got better and better, now just about any damn thing I want out of a sound system in computer just works, works reliably and better than any system I have ever used under windows or mac osx. Any person who complains about pulseaudio nowadays, who isn't doing stuff that requires jack anyway(high end professional recording stuff), simply does not remember what a friggin nightmare sound configuration was even a handful of years ago. Every program that does audio had to support artsd, esd, jack, ossv3 and ossv4, alsa dmix etc. Hell has a special place reserved for those who came up with the alsa configuration system. Unless you had one of a half-dozen cards that supported hardware mixing it was not possible to play two sounds at the same time, then it eventually became possible via dmix, but configuring it and getting it to work was a friggin nightmare. Now I can have any number of audio programs running at the same time, can direct their inputs and outputs at will at any time, I can control the volume of each application separately, I can even normalize the sound or run a full-blown equalizer. If i walk out of range with my bluetooth headset on it simply switches over to speakers and returns once my headset syncs again. My 5.1 digital optic audio just works! no more hundreds of hours trying to find the right multichannel mapping for sound, wow, just wow, were almost civilized.

        Poettering is all about linux plumbing. You know that unsexy works that nobody likes but we each depend on. However when you change the infrastructure you end up having to adjust some number of other things to work properly. One thing that has always eluded me, is the whole class of applications which run under linux which are not normal "user processes". Things like the display server, ltsp, web servers, databases etc. These things do not fit into the category of user applications, because they require system reconfiguration, and because they are not session bound(anything that is not working my data, available under my account when I log in, is not in my book my "user process"). This class of applications needs to run at once with more(elevated) privileges than a normal user, but at the same time less-ie. they require a managed environment which enables them to run securely at a privileged level, yet still limited in regards to where and how they access data(sandboxing does some of this, running such processes under dedicated users, like dhcpd etc., does some of this too, but neither fully captures the semantics of such application "personalities" for lack of a better word. Cgroups and systemd's PID #1 is an approach to begin martialing such.

  • Pure Insanity (Score:5, Interesting)

    by somenickname ( 1270442 ) on Sunday May 29, 2016 @07:36PM (#52207721)

    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?

  • by hcs_$reboot ( 1536101 ) on Sunday May 29, 2016 @09:05PM (#52208131)
    Log out = no more of your processes. Normal. Having "nohang" processes, for a regular user != root, is the exception.
    • Log out = no more of your processes. Normal. Having "nohang" processes, for a regular user != root, is the exception.

      If by "nohang" you mean "nohup", then, yes, it is an exception, in the sense that you have to run the command with nohup.

      However, with the configuration change being discussed here, nohupping a process apparently isn't sufficient to allow it survive a logout.

  • by dbIII ( 701233 ) on Sunday May 29, 2016 @11:20PM (#52208669)
    These people (Lennart et al) just do not get the concept of a multiuser operating system so it makes perfect sense to them.
  • by MrKaos ( 858439 ) on Monday May 30, 2016 @03:49AM (#52209333) Journal

    Despite ongoing challenges, I am yet to see a use case presented that the existing initd system cannot handle if you take the time to understand how to use it properly.

    I genuinely want to know why systemd is better than initd? As now I am being told that I'll have to make modifications to the way somethings that have worked for years. Do you systemd proponents actually have *any* experience on enterprise systems and how hard it is to get root access to modify these behaviors?

    If you want systemd so badly - why don't you just make it a service of initd? Why are you guys, who cannot demonstrate you know any better, subjecting everyone to use this?

  • by Just Brew It! ( 636086 ) on Monday May 30, 2016 @05:41AM (#52209639)
    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.
  • One simple rule (Score:4, Interesting)

    by Damouze ( 766305 ) on Monday May 30, 2016 @07:29AM (#52209853)

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

  • by houghi ( 78078 ) on Monday May 30, 2016 @07:54AM (#52209939)

    I left Windows (when it was 95) for Linux, because all I could do more was copy/paste some things into the regedit that I had no real idea what they were doing.

    With Linux I had a system that I could do things myself (and screw it up myself).

    Now we have a BIOS that wants to do everything, running a boot loader that wants to do everything staring a GUI that wants to do everything with a Desktop that wants to do everything that runs a browser that wants to do everything to visit a site that wants to do everything.

    And if you have an issue, they all yell "It wasn't me." and point their fingers to others as if they are toddlers who stole candy.

  • by ACE209 ( 1067276 ) on Monday May 30, 2016 @08:12AM (#52210021)
    systemd seems to want to fix the problem that Linux is a successful server OS.
  • *slow clap* (Score:4, Insightful)

    by OrangeTide ( 124937 ) on Monday May 30, 2016 @10:14AM (#52210477) Homepage Journal

    Systemd, you've solved a problem that was never really much of a problem.

3500 Calories = 1 Food Pound