Slashdot Mirror
Systemd Starts Killing Your Background Processes By Default (blog.fefe.de)
New submitter nautsch writes: systemd changed a default value in logind.conf to "yes", which will kill all your processes, when you log out... There is already a bug-report over at debian: Debian bug tracker.
The new change means "user sessions will be properly cleaned up after," according to the changelog, "but additional steps are necessary to allow intentionally long-running processes to survive logout. To effectively allow users to run long-term tasks even if they are logged out, lingering must be enabled for them."
The new change means "user sessions will be properly cleaned up after," according to the changelog, "but additional steps are necessary to allow intentionally long-running processes to survive logout. To effectively allow users to run long-term tasks even if they are logged out, lingering must be enabled for them."
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 >
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.
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)
> 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.
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.
> 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.
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.
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
Systemd is a pain.
aaaaaaa
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.
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.
On a reasonably POSIX system, yes. Apparently not in POTTERIX.
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.
That systemd is able to kill the remaining processes on logout is not an issue. What is an issue is that it does this _by default_.
Why is that an issue? Even the old SysVinit distros did the same (albeit not very well). If you are thinking about the user wanting to run certain processes after logout, then that isn't a problem at all; just tell the system so. You do that by starting the process in its own scope with "systemd-run --user --scope `program` ". It really is that simple.
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.
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?
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.
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.
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.
But we have also always been able to identify and route around said phenomena.
Well, we still can; I will always refuse to use any distribution that comes with systemd installed. I don't care what that gaping vagina Poettering thinks, there's nothing fundamentally wrong with svr4 and whatever "problem" systemd aims to "solve" simply doesn't exist to begin with.
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.
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?
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.
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.
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.
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.
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. The other alternative may be to add an extended attribute to the screen executable or other sort of thing that says "please don't kill me, I'm meant to linger, honest"
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 !
"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.
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'?
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.
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.
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.
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.
Systemd, you've solved a problem that was never really much of a problem.
“Common sense is not so common.” — Voltaire