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

Comments

security best practice?

[Anonymous Coward]

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 >

Re:security best practice?

[Anonymous Coward]

you should explicitly state so

nohup

Re:security best practice?

[drinkypoo]

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.

Re:security best practice?

[Anonymous Coward]

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.

Re:security best practice?

[l3v1]

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.

Re:security best practice?

[jsm300]

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.

Re:security best practice?

[MrKaos]

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.

Exactly.

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.

Re:security best practice?

[Junta]

Systemd developers then say that tmux, screen, nohup, etc are all broken

This is the phenomenon that pisses me off the most. They know these well-known applications exist, and precisely how they work and how *nix systems conventions work, and then have the gall to say that *everyone* else has a 'bug' because systemd decided to throw all that out. They don't say that it would be ideal if these other applications would add features, they say 'oh, they are buggy' to make users go away. It's an insane amount of hubris.

Just fix the docs...

[msauve]

"user sessions will be properly and improperly cleaned up after..."

FTFY.

systemd: Repeating past mistakes since 2010

[Anonymous Coward]

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.

Re:Well fuck you, systemd

[Lumpy]

Or you know use Slackware... it's the oldest Linux Distro and does not use systemd.

WTF

[BlackPignouf]

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

[AmiMoJo]

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

[aardvarkjoe]

If I have to know that a particular system is using systemd in order to invoke "screen" correctly, somebody's design is totally broken.

Re:WTF

[Gaygirlie]

"screen" will work exactly as it always have, even with the new defaults.

Except that the way you describe is not the way that screen has always worked. Instead of the straightforward invocation screen on the command line, now it has to be prefixed with all kinds of systemd-specific stuff that wasn't there before.

Its functionality is the same. Really, just use an alias if typing is hard for you to do. Or even better. Start screen automatically at boot by running it as a .service. See the Arch wiki for how.

Seriously? "Jump through extra hoops and it'll work like it always did?" If you have to jump through such stupid extra hoops then it fucking doesn't work like it always did! Being able to run stuff in the background has been around for decades and it's one of those things that I make heavy use of and there is already a perfectly good, valid API and everything for that -- I haven't jumped on the systemd hate-train before, but a change like this for zero fucking good reason is pushing me over the edge, too.

Re:WTF

[l3v1]

"Because there is not other way for logind to determine that "screen" was one of the things a user actualy intends to keep running, or something that is still running because it's exit logic is misbehaving."

Bad point of view. It shouldn't be systemd's task to decide who is running properly and who is not. If a process lingers because of some bad behavior or bug, than that should be corrected, but assuming every process is an idiot and should be killed is very stupid. The default behavior should be - as it always was - that if a process is running after the user left, does so intentionally. Such decades old expected behavior should not be changed because of some idiot thinks everyone's usage patterns fits his own.

I was lucky to read about this before I updated to this new systemd version (which I didn't), but we can't assume everyone will read about it, they're in for a real treat.

Re:WTF

[Etcetera]

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:

In my view it was actually quite strange of UNIX that it by default let arbitrary user code stay around unrestricted after logout. It has been discussed for ages now among many OS people, that this should possible but certainly not be the default, but nobody dared so far to flip the switch to turn it from a default to an option. Not cleaning up user sessions after logout is not only ugly and somewhat hackish but also a security problem.

...

I am pretty sure we should consider it our duty as Fedora developers to improve the Linux platform, and I am pretty sure that properly cleaning up processes on logout is a step towards that, not against it.

Re:WTF

[shutdown -p now]

Your analogy is hilariously bad.

Moving from telnet to ssh was a visible break - command name is different, syntax is different, configuration is different etc. If you are a guy who's used to telnet, and you find yourself on a machine that only has ssh, you know that things aren't going to work the way you used to right away, and there's no possibility of confusion - you have to go read the docs etc.

What happened here is a quiet breaking semantic change to an existing invocation. If you type "screen", it still works, and it even behaves as you'd expect. As an experienced user, you know how it's going to behave from there, and you have no reason to expect that behavior will deviate from your expectations (in a potentially destructive way at that!) with no warning.

Re:WTF

[aaronl]

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.

To be quite honest...

[Noryungi]

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.

Re:I assumed this was already a default

[Anonymous Coward]

> A multi-user system shouldn't allow unpriviledged users from consuming resources indefinitely

You're an idiot.

If I log on and start vim and two weeks later I've still got that screen sesh up, I sure as fuck do not want my unpriviledged account to have its processes terminate.

Docking/shutdown makes sense. You've turned off that (conceptual) computation device. But that requires the end user to say they're done and shut down. Doing it automatically is incredibly fucking stupid.

Re:From a security perspective...

[silas_moeckel]

Because for most linux is not a desktop os, we use it one servers. I've had logged in screen sessions that date back to when machines were built. Systemd keep thinking that people want it for a desktop os, for their laptop etc. I've got literally thousands of physical boxes running linux that I deal with I've only got one linux laptop so the laptop scenario should never be the default for me, the systemd devs seem to keep thinking their linux laptops are the majority.

Sorry, Slackware is NOT an option. Nor is Gentoo.

[Anonymous Coward]

Again and again I've heard people like you suggest that Slackware is a replacement for a modern mainstream distro like Debian. Others suggest Gentoo.

Well, the reality is that neither is sufficient.

Slackware is, to put it politely, very primitive. While simplicity is a good thing, Slackware takes it to the point where it becomes a liability.

When using Debian, it's possible to get a full-featured desktop or server set up with very little effort, and this can be done quickly. Thanks to sensible defaults and a practical installer, manual configuration is kept to a minimum.

Slackware, on the other hand, requires far too much manual intervention just to get a minimally usable system set up. Maybe this isn't a problem for a hobbyist who tinkers with Linux on a weekend, but it is a problem for people who are seriously using Linux, especially in a business setting. They can't afford to waste time and effort on Slackware, especially if a distro like Debian manages to avoid such waste.

Gentoo really isn't much better. It's not as bad as Slackware, but Gentoo is still a niche distro, and its whole compilation strategy is wasteful for anyone but hobbyists.

At this point, sensible and experienced Debian users have realized that Debian systemd/GNU/Linux is a lost cause. They've moved to FreeBSD ages ago, or are in the process of doing so. If Slackware and Gentoo are the only viable non-systemd options left for those who want to use Linux, then Linux is just not suitable for use.

FreeBSD gives much of what Debian used to give: stability, reliability, trustworthiness, an excellent packaging system, a superb installer, sensible defaults, no systemd, and an environment that's perfect for both desktops and servers. In some ways FreeBSD is even better than Debian traditionally was: much of the FreeBSD code is released under truly free BSD family licenses, rather than the far more restrictive and less-free GPL family.

Re:I assumed this was already a default

[Anonymous Coward]

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?

Re:I assumed this was already a default

[sjames]

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.

It's all Gnome's fault

[the_B0fh]

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

Re:It's all Gnome's fault

[JohnFen]

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.

Re:I assumed this was already a default

[CanadianMacFan]

So I log onto a server, start a all-night process, log off, and shut down my desktop it should mean that my process should also be killed? Or do I have to keep my desktop on all night and hope that the connection doesn't drop just to keep the process running?

Or sometimes I can log on to a system to start a long process which will send me a notification when it's done. Why should I stay logged in taking up resources just so that the process can stay running? It's better for the system for the process to be running in the background and me to be logged off. If I do things properly I set up my job to run at a lower priority but the OS is going to have a good scheduler to ensure that active users are given priority.

Re:I assumed this was already a default

[sjames]

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.

Re:I assumed this was already a default

[lucm]

How is the old way a problem?

That's systemd in a nutshell (and pulseaudio too). Replace well-known things that are not broken with something obscure and clunky that thinks it's smarter than you.

systemd, unity, iTunes, Windows 10... We live in a world where mediocre aspies decide how other people should use their computers because they work in large footprint organizations that have no competent dictators.

Re:A total non story ..

[Anonymous Coward]

It _is_ an important story. It is yet another demonstration of the Systemd Cabal's willingness to change _long-standing_ default behaviors without significant fanfare, notice, or adequate justification.

There are far more Linux servers and "appliances" in the world than desktop machines. Many of those non-desktop machines happen to run Debian, Ubuntu, or another systemd distro. If one is considering changing a default behavior, one must keep this fact in mind. It's clear that the Systemd Cabal failed to do so in this case.

Re:Thats demonic

[Anonymous Coward]

This is anti-daemonic. Systemd is committing daemon genocide while you log out and turn your back on it.

Pure Insanity

[somenickname]

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?

Re:I assumed this was already a default

[tburkhol]

One of the best things on linux is screen. I can start a long calculation, compile, transcode, whatever, log out, drive home, and pick up where I left off. Let the computer work while I drive: there's no reason for it to be stuck in traffic, too.

Re:I assumed this was already a default

[JohnFen]

Even with the new settings, no user process will be killed on exit/logout if the user have told the system not to.
Instead of starting the program with with "nohup" you start it with "systemd-run" instead.

Yes. The issue isn't that it can't be done. The issue is that longstanding default behavior has changed. Since it appears that there's no good, solid reason for the change, people are objecting to it. Change for change's sake is bad.

Re:I assumed this was already a default

[Ken D]

Because they are remote headless systems and I don't need to stay connected to them in order for them to do the stuff I want them to do?

Re:A total non story ..

[Guy Harris]

The issue is the violation of POLA (principle of least astonishment) given that Unix has allowed processes to run after user exit through nohup(1), which dates back to at least 1986:

More like "at least 1975" - nohup dates at least back to V6.

Re: I assumed this was already a default

[N!k0N]

And nohup up is what systemd is breaking in this "update" ... do try to keep up.

Systemd is *more than* a pain

[Taco Cowboy]

... Systemd is a pain ...

Basically systemd is built on a totally fucked up concept - a concept in which whatever the users do is not important, only system resources count, and if the users do not like it, they can go fuck themselves

That is basically what systemd is - and it perfectly reflects the way systemd's proponents think as well

Still no compelling systemd use case

[MrKaos]

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?

Good in theory, bad in practice

[Just Brew It!]

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.

Re: I assumed this was already a default

[fluffernutter]

Apologies.. Killing nohup'd processes is so undeniably stupid I read the summary wrong.