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

security best practice? by Anonymous Coward · 2016-05-29 09:39 · Score: 4, Insightful

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? by Anonymous Coward · 2016-05-29 10:13 · Score: 5, Informative

you should explicitly state so
nohup
Re:security best practice? by Archfeld · 2016-05-29 11:36 · Score: 3, Insightful

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.

--
errr....umm...*whooosh* *whoosh* Is this thing on ?
Re:security best practice? by Anonymous Coward · 2016-05-29 11:58 · Score: 2, Interesting

tmux.
How are you supposed to run tmux if systemd goes killing background processes when you logout?
Re:security best practice? by fluffernutter · 2016-05-29 12:12 · Score: 2

Or CTRL-Z / bg / disown if you forgot the nohup &

--
Laws are rules for the court, but merely a bottom bar to hit for life. Think beyond laws in your actions always.
Re:security best practice? by drinkypoo · 2016-05-29 12:59 · Score: 5, Insightful

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.

--
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
Re:security best practice? by See+Attached · 2016-05-29 15:30 · Score: 2

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 should have an rational/understood behavior profile. (oh.. and post below... a command launched with Nohup.. Since its an AC, cant attribute.)

--
Time for a new Political party in the US (or two!) One is off the rails Other cant pony up a leader.
Re:security best practice? by Anonymous Coward · 2016-05-29 15:30 · 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.
Re:security best practice? by l3v1 · 2016-05-29 17:17 · Score: 5, Insightful

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.

--
I am putting myself to the fullest possible use, which is all I can think that any conscious entity can ever hope to do.
Re:security best practice? by jsm300 · 2016-05-29 17:43 · Score: 5, Informative

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? by MrKaos · 2016-05-29 18:27 · Score: 5, Insightful

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.

--
My ism, it's full of beliefs.
Re:security best practice? by Junta · 2016-05-30 01:10 · Score: 4, Insightful

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.

--
XML is like violence. If it doesn't solve the problem, use more.
Re:security best practice? by segedunum · 2016-05-30 03:49 · Score: 3

Errrrr, no. Reading the manual is a waste of time because default behaviour is being made up on-the-fly - as always.

nohup, screen etc. have always persisted beyond the end of a session and this has been expected behaviour for the past thirty years or so. Anything that changes that is a bug and needs to be fixed. Default behaviour already cleans up on logout if processes aren't detached from their parent process so this shouldn't be a problem.

Fucking up expected and long-standing behaviour because Gnome can't clean up after itself, and where this is the 'fix', is total nonsense. God knows what other behaviour this will fuck up.
Re: security best practice? by segedunum · 2016-05-30 07:41 · Score: 2

who needs to be sure that users who have left the employ of the organisation don't have the ability to run commands anymore.
This is a highly complex process of removing their user logins.

Without this control available, I need to check every server for screens or nohup'd processes (we already have controls in place for at, cron etc.).
What gives you the idea that this is what it will do? Users have a wide variety of reasons for running screen, and under systemd you're still going to have to make provision for users to run screen and nohup etc........because they're useful. It is not going to run round all your servers and clean up long running processes.

This has been a real risk in the past on real servers currently running sysvinit.
What's sysv got to do with this? Ahhh, yes, I see what's going on here........ ;-).

With this systemd feature, it would make my life easier, because on the two bastion/hop servers, I would disable this and audit processes on these servers when removing/locking accounts.
Disable what? So they'd only be able to do 'unsafe' stuff while they are logged in? ;-) Why do you think this will improve security? Are you not auditing already when you remove user accounts? I can't figure what on Earth you think will be improved here.

No, just because sysvinit can't enforce it well doesn't mean no-one needs it.
This has nothing to do with sysv...........
Re:security best practice? by ohmiccurmudgeon · 2016-05-30 09:04 · Score: 2

Evidently the systemd developers forgot about the concepts of "controlling terminal" . Remember the days when you forked a process twice to divorce it from its controlling terminal or pty? To keep such processes from running forever you actually used ulimit to limit the resources a process could consume. There is no need for more intervention from the likes of systemd.
How do we unravel systemd from our systems?
Re:security best practice? by somenickname · 2016-05-30 10:59 · Score: 2

It's actually a lot worse than you suspect. Research it a bit and you'll understand the underlying motivation. Basically, these morons have decided to break the traditional process hierarchy model and are spawning user processes "out of band". So, they don't have a reliable way to make those processes shutdown. This insane hack is their solution to fixing the problem that they created. You can't rely on screen working correctly anymore because sometimes the PulseAudio daemon doesn't correctly shut down. Not even fucking joking.

It's still hungry... by QuietLagoon · 2016-05-29 09:39 · Score: 3, Funny

Better feed it. :)

Just fix the docs... by msauve · 2016-05-29 09:43 · Score: 5, Funny

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

FTFY.

--
"National Security is the chief cause of national insecurity." - Celine's First Law

systemd: Repeating past mistakes since 2010 by Anonymous Coward · 2016-05-29 09:48 · Score: 4, Insightful

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 by Lumpy · 2016-05-29 09:49 · Score: 4, Informative

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.

WTF by BlackPignouf · 2016-05-29 09:49 · 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.

Re:WTF by AmiMoJo · 2016-05-29 10:16 · Score: 4, Insightful

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.

--
const int one = 65536; (Silvermoon, Texture.cs)
SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
Re:WTF by sjames · 2016-05-29 11:04 · Score: 3, Insightful

On a reasonably POSIX system, yes. Apparently not in POTTERIX.
Re:WTF by CRCulver · 2016-05-29 11:16 · Score: 3, Insightful

"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.
Re:WTF by aardvarkjoe · 2016-05-29 11:42 · Score: 4, Insightful

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

--

How can we continue to believe in a just universe and freedom to eat crackers if we have no ale?
Re:WTF by myowntrueself · 2016-05-29 12:00 · Score: 2

"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.
The first thing I thought of when I saw the headline was "Has Poettering heard of or used screen?" Evidently he's heard of it but doesn't seem to be a user.
This is yet another example of violation of the Principle of Least Surprise on the part of the systemd team.

--
In the free world the media isn't government run; the government is media run.
Re:WTF by Kernel+Kurtz · 2016-05-29 12:45 · 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....
Re:WTF by Megol · 2016-05-29 12:48 · Score: 2

In the same vein I didn't fuck your mother - yet.
Re:WTF by Gaygirlie · 2016-05-29 13:06 · Score: 5, Insightful

"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 by RightwingNutjob · 2016-05-29 14:16 · Score: 3, Insightful

You really don't get what people are trying their damnedest to explain to you. Invoking the command is part of running it. If you change the effective behaviour of the command when it is called with its standard invocation, then you have changed the behavior of the command.

And I guess I have to say this, even though I shouldn't have to say it to anyone older than ten: If you change the way a command is invoked, it is not the same thing; it is a different thing, that may or may not do the same thing, but even if it does, the fact that you call it with a different command means it is not the same thing. More to the point, the fact that it is not only NOT THE SAME THING but also BREAKS THE ORIGINAL THING by changing its functionality means that one idiot with a God complex thinks it's OK to make everyone else scramble to change their code so that it keeps working. And there is no good reason for it. That's bad engineering, bad customer relations, bad stewardship of OSS, and bad karma, for lack of a better term.

If you were working on a project for me and tried to pull something like that, I'd fire you. If you were working with me and not for me, I would have you fired. And at the very least, I'd punch you in the mouth. The last bit is for having the unique combination of chutzpah and stupidity to tell me that your change isn't really a change if I change what I'm doing to meet your newly-discovered aesthetic standards for command invocation.
Re:WTF by Curunir_wolf · 2016-05-29 15:48 · Score: 2

You just start screen, either as a proper .service or as a transient service in its own scope using : "systemd-run --user -scope screen". This will make screen run in its own scope so it won't be destroyed when the users scope is purged at logout.
Why? Why do I have to invoke an obscure systemd command to do something I've done without referencing the OS init system? Do all my bash scripts now need to change to work with systemd?

--
"Somebody has to do something. It's just incredibly pathetic it has to be us."
--- Jerry Garcia
Re:WTF by RightwingNutjob · 2016-05-29 16:17 · 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.
Re:WTF by dbIII · 2016-05-29 17:11 · Score: 2

I think the systemd developer group is the single most knowledgeably Linux developer group when it comes to multi-user Linux
Definitely trolling. What an utterly useless waste of space you are.
Re:WTF by l3v1 · 2016-05-29 17:32 · Score: 4, Insightful

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

--
I am putting myself to the fullest possible use, which is all I can think that any conscious entity can ever hope to do.
Re:WTF by Dog-Cow · 2016-05-29 17:52 · Score: 2

Really? No other way? So screen working for all these decades has been happy coincidence?
Re:WTF by Etcetera · 2016-05-29 18:10 · Score: 5, Informative

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.

--
Hire a Linux system administrator, systems engineer,
Re:WTF by shutdown+-p+now · 2016-05-29 20:59 · Score: 4, Insightful

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 by aaronl · 2016-05-30 01:04 · Score: 4, Informative

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.
Re:WTF by sconeu · 2016-05-30 09:06 · Score: 2

I think it's clear that the end goal of systemd is to be its own operating system, providing all services to the programs that run on top of it.
Yeah, but when will it get a good init system?

--
General Relativity: Space-time tells matter where to go; Matter tells space-time what shape to be.

Re: Well fuck you, systemd by ArmoredDragon · 2016-05-29 09:53 · Score: 2

You use old beater machines instead of virtual machines? God I remember when I did that... So much clutter due to holding on to old computer parts that I'd usually never end up using, but still keeping them "just in case". My last move was so much easier without packing up a garage partially filled with that shit to bring to the next house.

To be quite honest... by Noryungi · 2016-05-29 09:54 · Score: 5, Insightful

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.

--
The right to offend is far more important than the right not to be offended. (Rowan Atkinson)

Re:To be quite honest... by Waffle+Iron · 2016-05-29 13:03 · Score: 3, Insightful

You just start them with "systemd-run --user --scope screen" and everything works as before

No it does not work as before. Before you just typed "screen", and it worked on any system.
Life is too short to spend time committing all that extra crap to memory or else having to configure every system you touch with custom shortcuts.
If you think that having to remember to type "systemd-run --user --scope-screen" in front of a frequently used utility (and having the system silently clobber your work if you forget) is reasonable, you're deluded.
Re:To be quite honest... by Waffle+Iron · 2016-05-29 13:53 · Score: 2

In Unix and its derivatives, frequently used commands are terse. If there's something new for me to learn, it ought to be a half-dozen keystrokes.
No, I am not going to learn to use a new command that has over 40 extra keys to type to support a misfeature that has no benefits to me. No, I am not going to look up that damned command sequence in the man pages every time I'm on a new system and it's not in the history stack.
No other Unix command line utility imposes that burden on the user.
As I originally suspected, you are delusional.
Re:To be quite honest... by nyet · 2016-05-29 15:09 · Score: 2

"nohup" exists on every machine.
Your "systemd-run" twaddle does not.
Re:To be quite honest... by dbIII · 2016-05-29 16:20 · Score: 3, Insightful

The old init systems are creaking under the weight of many patches, scripts and hacks
That was the propaganda but the reality can be seen in those distros and operating systems that do not use SystemD and are not "creaking". SystemD is nothing but a "grand unification" project where a single group is trying to take over all of those patches, scripts and hacks, but since they are new at it and don't seem to fully understand what they are working on there are teething problems.
Notice how the initial promises about "speed" quietly went away?

Re:I assumed this was already a default by Anonymous Coward · 2016-05-29 09:57 · Score: 5, Insightful

> 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:Well fuck you, systemd by whoever57 · 2016-05-29 09:58 · Score: 2

Or Gentoo. systemd is optional on Gentoo.

--
The real "Libtards" are the Libertarians!

Re:I assumed this was already a default by hviezda14 · 2016-05-29 10:02 · Score: 2

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

Crippling the service is not a good way to protect the server.

There are other ways to protect system from users to consume all the resources. Admin can and should setup the server the way it is protected from incompetent/malicious users.

If you make this protection by killing processes after logout, you are actually removing functionality from it. And for me, it's a step backward.

Re:From a security perspective... by silas_moeckel · 2016-05-29 10:04 · Score: 5, Insightful

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.

--
No sir I dont like it.

Re:I assumed this was already a default by Anonymous Coward · 2016-05-29 10:10 · Score: 3, Insightful

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

man 5 limits.conf

In short, *nix has provided ways to do just that for literal decades.

Sorry, Slackware is NOT an option. Nor is Gentoo. by Anonymous Coward · 2016-05-29 10:12 · Score: 5, Insightful

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.

egotistic breakage charisma by epine · 2016-05-29 10:14 · Score: 2

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.

Re:I assumed this was already a default by Anonymous Coward · 2016-05-29 10:28 · 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?

A total non story .. by khz6955 · 2016-05-29 10:30 · Score: 2, Informative

"it should rather be disabled .. by setting KillUserProcesses=no in /etc/systemd/logind.conf ." ref

Re:A total non story .. by Anonymous Coward · 2016-05-29 11:10 · Score: 4, Insightful

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:A total non story .. by Guy+Harris · 2016-05-29 13:32 · Score: 4, Informative

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 by sjames · 2016-05-29 10:47 · 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.

It's all Gnome's fault by the_B0fh · 2016-05-29 10:50 · 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?!

Re:It's all Gnome's fault by somenickname · 2016-05-29 12:03 · Score: 2

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.
Re:It's all Gnome's fault by JohnFen · 2016-05-29 13:08 · Score: 5, Insightful

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:It's all Gnome's fault by AFCArchvile · 2016-05-29 15:10 · Score: 2

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 bazaar", where both userspace and kernel development can be seen by those watching mailing lists, there's no remorse, or even self-awareness, to these kinds of changes. Perhaps even the developers of Service Control Manager over at Microsoft are laughing about this, and they fully deserve to have a chuckle. We'll have to wait until the termination of someone's tmux results in a half-million-dollar loss.
Systemd needs some serious road-testing, since we're stuck with it now that all of the distros have force-fed it to Linux users. It desperately needs a maintainer with a base level of systems discipline. Perhaps a sysfs interface shim for the spaghetti mess of config files would help? For all the complaints about init, at least it was easy to understand, and wasn't weighed down by the object-oriented word salad prone to be spouted out by the 2000's-era CompSci textbook-transcribers who are plaguing software development these days.

--
"Ancillary does not mean you get to rule the world." --U.S. Circuit Judge Harry Edwards, speaking to the FCC's lawyer
Re:It's all Gnome's fault by mvdwege · 2016-05-29 18:32 · 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'?
Re:It's all Gnome's fault by iwbcman · 2016-05-30 00:15 · Score: 3, Insightful

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.

Re:I assumed this was already a default by CanadianMacFan · 2016-05-29 10:50 · Score: 4, Insightful

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 by sjames · 2016-05-29 10:53 · 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.

Re:From a security perspective... by Peter+H.S. · 2016-05-29 10:54 · Score: 3, Funny

The functionality remains the same, even with the new systemd defaults. But instead of using "nohup /program/ &" you use "systemd-run --user -scope /program/".

So a slight change in syntax, not a big deal IMHO.

Re:From a security perspective... by Guy+Harris · 2016-05-29 11:00 · Score: 2

You morons all sound like a bunch of Mac users.

Actually, if, on a Mac running OS X, you do nohup blahblahblah >/tmp/blahblahlog 2>&1 & in a Terminal window in a GUI session, and then log out and log back in again, blahblahblah will still be running (verified experimentally on an El Camino (virtual) machine just now).

(If it warns you that there's a process running in Terminal, and that logging out will kill it, tell it to close the Terminal window anyway; it's lying, the process will survive. I'm not sure what signal is getting sent, if any, but it ain't SIGKILL - perhaps it's SIGHUP, as nohup's purpose is to make the process ignore SIGHUP.

The Unix tradition has always been "you want your backgrounded processes to survive a logout, nohup them" - traditionally, when the tty driver saw that carrier dropped, it'd deliver SIGHUP, although I'm not sure all UN*Xes pseudo-terminal drivers deliver SIGHUP when the master side closes, that being the closest moral equivalent to carrier dropping; I think I've seen that not happen on OS X, but didn't dig through the pseudo-tty code in XNU enough to see why that wasn't happening or to determine whether that was intentional.)

Re:I assumed this was already a default by lucm · 2016-05-29 11:04 · Score: 5, Insightful

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.

--
lucm, indeed.

Re:I assumed this was already a default by turbidostato · 2016-05-29 11:34 · Score: 2

"Wouldn't it be better to save state on logout and restore on login?"

Wouldn't it be better if you learn that for the computer to do things on my behalf it's not needed that I stay in front of the computer, that I don't even need to maintain an interactive session opened for that to happen?

Re:Thats demonic by Anonymous Coward · 2016-05-29 11:35 · Score: 5, Funny

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

Pure Insanity by somenickname · 2016-05-29 11:36 · 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?

Re:Pure Insanity by somenickname · 2016-05-29 14:28 · Score: 2

No, my primary machine has no traces of systemd or PulseAudio or any other ultra-invasive piece of software. And it's the most stable, reliable machine I've ever used. By a huge margin. Inviting these ill-advised RedHat technologies onto your machine is just asking for trouble. They are *not* needed in a workstation or server environment. I honestly have no idea why a distro like debian would adopt them. They genuinely detract from the traditional stability of something like debian. I find it absolutely shocking to see systemd as a default in debian. And, if you are a debian user, it's non-trivial to exorcise systemd.
Re:Pure Insanity by somenickname · 2016-05-29 16:18 · Score: 2

I think it's both. It's systemd for deciding that this is a sane default behavior and the debian guys for not having the balls to stand up to this bullshit. If you read the bug report linked in the summary, you'll see someone with an @debian.org address say what effectively amounts to, "This seems like a good idea for my laptop and, I can't imagine we have many users that are different from my laptop". Not even fucking kidding: https://bugs.debian.org/cgi-bi.... So, yes, debian is at fault for not having the fortitude to put this garbage in the bin. But, the filth didn't originate from debian.

Re:I assumed this was already a default by tburkhol · 2016-05-29 11:46 · Score: 5, Insightful

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: Well fuck you, systemd by Bing+Tsher+E · 2016-05-29 11:49 · Score: 2

In the movie Fahrenheit-451 you're the dude gleeful that all the clutter is being cleared away.

Re:I assumed this was already a default by sjames · 2016-05-29 11:57 · Score: 3, Insightful

So other than again pointlessly changing the well known and understood API, what's the point of systemd again? How about just leave things the way they were?

That is, when the tty disconnects, it sends SIGHUP to the processes it controls. It's up to those apps to determine what is the right thing to do upon recieving SIGHUP.

Re:I assumed this was already a default by Anonymous Coward · 2016-05-29 12:01 · Score: 2, Insightful

It's not the aspies fault. It's the organizations as a whole going for the lowest common denominator. Google Chrome, for instance just got rid of "backspace = prev page" because it was confusing for some users. Power users probably enjoyed this feature and all the other features that get axed because "not enough users/confusing for some" reasons, and the end result is the Duplo-ization of whatever the product is. A product that anyone can use without hurting themselves, but that advanced users will find very frustrating if they want to do anything interesting.

It isn't bad to have products like that in the market, but it's frustrating when all of the products follow that path.

Re: misleading title as usual by myowntrueself · 2016-05-29 12:04 · Score: 2

You are exactly correct. Distros will have the final say in conf defaults. I don't see many holding onto the yes value for server branded versions of their distros, way too much breakage. For desktop and workstation, maybe, we will have to see. But seriously, this whole thing is a massive overreaction to a value that can be changed in a text editor in less than two seconds. But of course we all know that any systemd news instantly makes front page because of the massive knee jerk Slashdot has for systemd.

Its something that, if you are unaware of the change, can break things badly, perhaps even messing up ability to remotely administer a server and have to call for remote hands. So IMO its something, the default behavior of which, should not change within a major release version.

However its also the sort of thing I could see a Debian package maintainer deciding is a 'security patch' and pushing it out to stable that way. Similar to what happened with sudo.

--
In the free world the media isn't government run; the government is media run.

Re:Sorry, Slackware is NOT an option. Nor is Gento by Anonymous Coward · 2016-05-29 12:36 · Score: 2, Funny

Sorry, but "Devuan" sounds like a half-black, half-Puerto Rican ladyboy. I can't seriously consider using it.

Re:I assumed this was already a default by JohnFen · 2016-05-29 12:42 · Score: 5, Insightful

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 by Ken+D · 2016-05-29 12:45 · Score: 4, Insightful

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:I assumed this was already a default by Anonymous Coward · 2016-05-29 12:52 · 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.

Re:I assumed this was already a default by Peter+H.S. · 2016-05-29 13:03 · Score: 2

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.

Why do you think there no solid reasons for this new default. It is something somebody told you, or are you just presenting what you imagine as facts?

Sorry but that's the normal behavior by hcs_$reboot · 2016-05-29 13:05 · Score: 2

Log out = no more of your processes. Normal. Having "nohang" processes, for a regular user != root, is the exception.

--
Slashdot, fix the reply notifications... You won't get away with it...

Re:Sorry but that's the normal behavior by Guy+Harris · 2016-05-29 13:50 · Score: 2

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.

Re:From a security perspective... by RightwingNutjob · 2016-05-29 13:07 · Score: 3, Insightful

Ah, but the price for using 'systemd's extensive resource management options' is that it breaks your workflow, shell scripts, and everything else you might have had that relied on 'nohup' or 'screen' working as advertised. That's not improving anything. That's a Mafia protection racket.

"Nice shell script you've got there. It would be a shame if something happened to it. Use this command to run it, or else, who knows what might happen. Fucking pathetic.

*For a concrete example, all of your scripts that automatically ssh into a server, start a process with screen, and log out, now break. To name just one thing that I have done on numerous occasions.

Re:I assumed this was already a default by LVSlushdat · 2016-05-29 13:22 · Score: 2

Or you can just not use systemd, if you dont like it then dont use it.

Easy to say, significantly LESS easy to do.. I use/prefer either Debian or Ubuntu, and am currently on Ubuntu 14.04.. Since both the latest Debian (Jessie) and Ubuntu (16.04) now have systemd, as do most other well-known distros. Its beginning to look like I'm going to have to back to my "Linux roots", namely Slackware, where I started, back in 1995, when Ubuntu 14.04 goes out of support in 2019. From what I can gather, Pat V hasn't (nor will he) pollute Slackware with Systemd.

--
THANK YOU, Edward Snowden!! Americans owe you a debt of gratitude (whether they know it or not..)

Re:Makes sense ... but ... by Guy+Harris · 2016-05-29 13:36 · Score: 2

Ordinarily, a user's processes SHOULD all be killed on logout. They're no longer logged on; they're no longer using or entitled to use the machine.

For better or worse, that hasn't been the way UNIX worked since at least the 1975-vintage V6 - you could use nohup, redirect the standard input/output/error, and run in the background to make a process be a job that survives logging out.

However, there will be cases where something long-term needs to go on. How hard is it to add daemons or background services in an administrator or batch context? That's where the long-term stuff should go. Olde days with VM/CMS: CMSBATCH was available to ordinary users if some job would run too long to be practical in foreground in the user account. Submit; it runs when scheduled (by the user or the system, depending on load) and returns results to the user account.

Perhaps UNIX should have had such a mechanism since the beginning, rather than later, for example, getting the at/batch command. For what it's worth, it didn't, only getting it later.

Slack FTW by inode_buddha · 2016-05-29 13:43 · Score: 2

That's pretty much what I did a couple weeks ago. Then I realized "wow, this is so nice and clean running! It does exactly what I want, the way I want it!" And that is the whole reason I started with Slack way back in 1996.... The thing about systemd and pulseaudio is that they provide exactly *zero* new features that I needed, whilst severely screwing with the system. I went thru RH, SuSE, Debian, and now back to Slack... RH in particular lately has been pulling some bonehead moves WRT the traditional Linux base.

--
C|N>K

Re: I assumed this was already a default by N!k0N · 2016-05-29 14:17 · Score: 4, Informative

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

As expected - not a bug a mindset by dbIII · 2016-05-29 15:20 · Score: 3

These people (Lennart et al) just do not get the concept of a multiuser operating system so it makes perfect sense to them.

Re:I assumed this was already a default by dbIII · 2016-05-29 15:28 · Score: 2

The pulse hate (of which I certainly spewed heavily at the time) was almost entirely due to flakiness

One of the more bizzare of which is you could speed up performance of X by blocking a port that pulseaudio listens to on the network. There should have been an option in pulseaudio to turn that absurdly resource hungry polling off instead of having to use iptables to block it.

Everyone in the distro world seems to be embracing it

Everything RedHat has put a lot of work into has been embraced, even NetworkManager and SystemD.

Systemd is *more than* a pain by Taco+Cowboy · 2016-05-29 15:29 · Score: 5, Insightful

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

--
Muchas Gracias, Señor Edward Snowden !

Re:From a security perspective... by dbIII · 2016-05-29 15:57 · Score: 2

Guys I think this Peter H.S. is deliberately trolling and is writing this ridiculous stuff just to get people angry.

Re:I assumed this was already a default by ras · 2016-05-29 16:03 · Score: 2

A multi-user system shouldn't allow unpriviledged users from consuming resources indefinitely. It's too easy to starve a system or resources. I think that's one of the reasons behind the isolation dockers provides in the first place. Shut down the container and everything gets cleaned up.

What "multi-user systems"? Multi-user systems died somewhere around the turn of the century, when the personal computers became common.

Secondly the people whinging about there do not give a shit about your concerns over large computer systems. And you should listen to them, because they are the people who run those systems. They are the sysadmins in charge of large clusters of machines they control with the likes of ssh, ansible and puppet. If there is a task left running when they log out, it is because they wanted it to be running.

All that aside, this is not 'nix having some issue with leaving processes running indefinitely when a person logs off. I've used 'nix of one version or another since V6 - and even back then it had a solution. When the user logged out, a SIG_HUP signal (so named because back then it was trigged by a modem hangup) was sent to all processes started by that login, and they were killed. So it's been a solved problem for 30 years.

The current problem is the caused by desktop guy's themselves. All the processes that drive their windowing systems needed to communicate, so they created one. Actually they've created several - corba, dcop, and now dbus. Initially they were used for communication configuration changes and such - eg, when you change the desktop font size everyone knew about it immediately, so the entire screen just changed. Then they found new uses for their toy - and soon it is used to communicate to backend daemons to do thing like bringing network interfaces up and down, which often required new processes to be created. That was followed by "address book servers", and "wallet servers" and god knows what else. In doing so they managed to break the old SIG_HUP system for desktop users, because their sometimes new processes weren't spawned by child processes of the login - they were instead spawned by system daemons.

So the desktop guys created a problem for themselves (only). The rancour you see here is the solution they have implemented and forced down everyone's throats breaks existing stuff. This is just laziness. If they insist on designing systems that have background daemons spawning per-session processes they could go to the effort of, you know, tracking them, so they can kill the bloody things when the session ends. Tracking things is after something computers do real well. Yes it would be more work - but they created the problem.

That said - if they were to go to the effort of accommodating legacy stuff (which they did in an exemplary way for the change from SysV init to to systemD init) by say offering up patches to the few programs that do leave stuff running in the background (nohup, term, screen, ...) I still wouldn't be satisfied. That is because what they have put together is a godawful mess, and this "solution" typifies it.

The first time I noticed the winding IPC monster was starting to grow is vim complained it could not save its settings ... when I was running it on a remote machine. wtf? Turned out they had pushed the tentacles of this mechanism to a remote VIM, and it was trying to save its settings on my laptop. Then ssh stopped shutting down properly - turned out because they weren't closing the IPC tunnels they had built. Then network connections started mysteriously changing their configuration - because the desktop had told network-manager who told a dhclient to do something with a virtual network device I had just created - wtf? It has since become evident that where before I could see state of my machines in static text files in well known places usually put there by me, now it was configured by inscrutable ephemeral messages being tran

Re: From a security perspective... by unrtst · 2016-05-29 17:10 · Score: 2

Or you could edit one line in one config file and get the behaviour you want back. No need to throw a hissy fit.

There is still a huge reason to throw a fit. If I need to kick off some background jobs on a bunch of machines reliably, I will now have to check how the system is configured first, and probably wrap that up in my own nohub-or-systemd-run wrapper, checking if systemd-run even exists, if so, how is logind.conf configured, then use the correct wrapper. All this why? Because some applications aren't respecting the conventions that have existed for ages, so let's make new ones?

Re:Sorry but that's the normal behaviorostost by mvdwege · 2016-05-29 18:37 · Score: 3, Insightful

A better approach would have been to have a group that had the ability to make processes run after logout. That would be a security improvement, since you could then determine which users had the rights to have persistent processes.

But that's exactly what systemd does! It gives you tools to run these processes in their own scope, so that their resources can be properly managed, and the admin knows that these processes are meant to hang around.

--
"I know I will be modded down for this": where's the option '-1, Asking for it'?

Re:From a security perspective... by Guy+Harris · 2016-05-29 19:22 · Score: 2

Actually, if, on a Mac running OS X, you do nohup blahblahblah >/tmp/blahblahlog 2>&1 & in a Terminal window in a GUI session, and then log out and log back in again, blahblahblah will still be running (verified experimentally on an El Camino (virtual) machine just now).

Harrumph El Capitan, d00d.

(If it warns you that there's a process running in Terminal, and that logging out will kill it, tell it to close the Terminal window anyway; it's lying, the process will survive. I'm not sure what signal is getting sent, if any, but it ain't SIGKILL - perhaps it's SIGHUP, as nohup's purpose is to make the process ignore SIGHUP.

To be fair, the OS X nohup, as well as, apparently, the OS X screen has been modified to call _vprocmgr_detach_from_console() , and that document is part of a version of tmux ported to OS X.

So perhaps screen, tmux, and nohup need to be modified to, on systems with systemd, do whatever the appropriate magic is necessary, just as is done on OS X.

Re:Thats demonic by arglebargle_xiv · 2016-05-29 19:35 · Score: 2

It's not the daemons I'm worried about, it killed my children! And ate my cat.

Still no compelling systemd use case by MrKaos · 2016-05-29 19:49 · Score: 4, Insightful

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?

--
My ism, it's full of beliefs.

Re:I assumed this was already a default by sjames · 2016-05-29 20:54 · Score: 2

Apt-get install sysvinit-core seems to fix it...

Re:I assumed this was already a default by sjames · 2016-05-29 21:10 · Score: 2

apt-get install sysvinit-core presents far fewer problems and future surprises. Why swat flies all day when I can just close the screen door?

Google "principle of least astonishment".

Beyond that, the question was "So other than again pointlessly changing the well known and understood API, what's the point of systemd again?", not "How can I turn/burn that particular wart off?

Good in theory, bad in practice by Just+Brew+It! · 2016-05-29 21:41 · Score: 4, Informative

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 by fluffernutter · 2016-05-29 22:47 · Score: 4, Insightful

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

--
Laws are rules for the court, but merely a bottom bar to hit for life. Think beyond laws in your actions always.

One simple rule by Damouze · 2016-05-29 23:29 · Score: 3, Interesting

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

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

Re:Rapists by jbolden · 2016-05-29 23:42 · Score: 2

The article is wrong. Systemd didn't change anything. Debian's config for systemd changed a default. Either option is a problem for people. But its not unreasonable to assume that users that want to have long running process know more about their systems and thus how to change them than users who want everything to stop when they logout. The change in default makes sense, and systemd is doing the right thing here.

What's a pain is the disruption caused by transitioning from a non-sensible default to a sensible default.

Re: I assumed this was already a default by Entrope · 2016-05-29 23:46 · Score: 2

So it's okay for malware to be running as long as you're logged in, but it has to stop when you log out?

That's the second stupidest thing I've read in this thread.

Gotta love computers these days by houghi · 2016-05-29 23:54 · Score: 2

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.

--
Don't fight for your country, if your country does not fight for you.

The problem systemd fixes by ACE209 · 2016-05-30 00:12 · Score: 3, Funny

systemd seems to want to fix the problem that Linux is a successful server OS.

--
"we are all atheists about most of the gods that societies have ever believed in. Some of us just go one god further."

*slow clap* by OrangeTide · 2016-05-30 02:14 · Score: 3, Insightful

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

--
“Common sense is not so common.” — Voltaire

Re:I assumed this was already a default by jbolden · 2016-05-30 02:35 · Score: 2

New system options

1) FTP command line registers with systemd that's its going to be doing a download over the next 12 hours from a slow server.
2) You run FTP from inside systemd telling the process manager this FTP is going to take 12 hours
3) After you start the FTP process you notify systemd

etc...

Re:I assumed this was already a default by segedunum · 2016-05-30 03:59 · Score: 2

Wouldn't it be better to save state on logout and restore on login?

Why?

This would provide the balance between saving system resources and allowing a user to start off where they left off.

What resources do you think you're going to be saving here? There are various ways of allocating resources to a user and they then use those how they want. restricting this to log on and log off is incredibly stupid.

Of course applications would need to be aware of state saving. Is there already some sort of API for this?

Jesus Christ. We don't need an API, or to add systemd support to anything because it ALREADY FUCKING WORKS.

Re:I assumed this was already a default by segedunum · 2016-05-30 05:39 · Score: 2

Correct. systemd is part of a broader system that is replacing POSIX.

ROTFL. Oh, right. systemd gets a new purpose in life every week. So, what happened to the init system then?

Re:Critical server on Sid? by segedunum · 2016-05-30 07:31 · Score: 2

...and would also know not to use Debian Sid on a critical server, BTW.

Errrr, Sid eventually turns into 'stable'........?

screen DOES work as intended as long as you care to correctly start it in its own seat/session/namespace/container (and all those non-POSIX-y stuff that Linux handles and that systemd manages)

Which doesn't qualify as working. Quite why people think something should have to be run differently when you are logged out as when you are logged in is truly mystifying.

Slashdot Mirror

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

114 of 924 comments (clear)