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

New submitter nautsch writes: systemd changed a default value in logind.conf to "yes", which will kill all your processes, when you log out... There is already a bug-report over at debian: Debian bug tracker.
The new change means "user sessions will be properly cleaned up after," according to the changelog, "but additional steps are necessary to allow intentionally long-running processes to survive logout. To effectively allow users to run long-term tasks even if they are logged out, lingering must be enabled for them."

Comments

security best practice?

[Anonymous Coward]

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

Re:security best practice?

[Anonymous Coward]

you should explicitly state so

nohup

Re:security best practice?

[Archfeld]

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.

Re:security best practice?

[Anonymous Coward]

tmux.

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

Re:security best practice?

[fluffernutter]

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

Re:security best practice?

[drinkypoo]

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

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

Re:security best practice?

[LesFerg]

But was this the systemd developers at fault or the person who build the installation package?
It sounds more like a lack of configuration with a .deb.

Re:security best practice?

[See Attached]

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

Re:security best practice?

[Anonymous Coward]

For me, it's not so much the poor quality; it's the poor quality, the arrogant/wontfix response to bugs, the 'adapt to us' attitude, the strawmen arguments, the ties to GNOME (quickly becoming its own shitheap), the idiotic assumptions and bad practices that throw out decades of learning and experience...and the fact that, despite all this, it's still being adopted.

Re:security best practice?

[l3v1]

Well, maybe because if you read the linked thread you'd see that screen/tmux/nohup/etc. are all affected by this idiotic change. Never liked the systemd philosophy, and their attitude even less, and such changes certainly won't make me like them.

Re:security best practice?

[Mashiki]

Pixie dust, don't use fairy dust or it'll install emacs, maybe vim if the fairy had it in for you. Blood for the Blood God will protect either from installing though.

Re:security best practice?

[jsm300]

How about doing anything that takes a long time and you don't want to remain logged in for it to complete? For example you are running a standard program that is going to take hours or even days to process some data, so you redirect stdin to /dev/null, stdout to one file, stderr to either the same file or another file, and you start the whole thing with the nohup shell command.

There is already a well established mechanism for cleaning up background processes, i.e. the SIGHUP signal. And there is already a mechanism for explicitly stating that you don't want a process to die when you log out, and that is the shell's "nohup" command (which blocks the hangup signal that is sent to the process when the user exits).

And in what way does this new mechanism "enhance security"? Running something in the background after you log out doesn't give you any more privileges than if you remained logged in.

Why do the systemd folks think they need to keep reinventing the wheel? This feels like a solution in search of a problem.

Re:security best practice?

[MrKaos]

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

Exactly.

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

nohup someProcess &

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

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

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

Re:security best practice?

[Barsteward]

https://wiki.archlinux.org/ind...

Re: security best practice?

[MrKaos]

Are you saying Windows is better than *nix in this case?

No, I am saying that the people pushing systemd are lobotomising *nix to windows levels of functionality and those who realize this is bad don't like it.

Re: security best practice?

[chaboud]

The systemd folk seem dead set on returning us to the days of single-user focused computing (e.g. Windows 95), and they have inexplicably decided to wreck an otherwise perfectly functional system (nohup).

But, you know... When I'm not logged in, I want my system to be as idle as possible, even if I explicitly told the system otherwise...

Galling, but not surprising.

Re:security best practice?

[jbolden]

The problem is the process shouldn't get to decide if they live forever that's the process manager's job. And ultimately on a shared system you as an unprivileged user likely shouldn't have the ability to run jobs consuming resources for days or weeks directly but rather through operations. That's not to say that there may not be reasons but some set of behaviors has to be the default and it seems sensible for me for operations / administration to default as regulating huge tasks rather than individual users and the software they run.

Re:security best practice?

[mikelieman]

Do you use screen or tmux?

Re:security best practice?

[Anonymous Coward]

Where in TFM does it show how to configure systemd to not allow systemd itself to stay up? That would be a welcome addition to TFM.

Re:security best practice?

[Junta]

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

See, I think this is an example of focusing on the wrong thing. The general argument being presented is that this is somehow perceived as a back door, or a resource hog. It's somehow scary.

On the backdoor part, there's really nothing that process should be allowed to do, by being allowed to continue running. It's still constrained by the privileges of that user. If there *were* something nefarious, backdoor wise, then your problem is with a failure of privilege, and preventing processes from running in the background will do nothing to really close the problem, that the user has the ability to take actions that they should not.

On the resource hog, again, the focus would be about how many resources they are allowed to consume, the fact of whether they are currently logged in or not is a red herring. If you don't want to allow a user to consume too many resources, you limit them, regardless of whether they are 'logged in' or not. That is why process accounting happened in the first place. CGroups add more sophisticated controls that are justified, but the 'session logout' part is superfluous.

Now I could see someone saying providing an option for anal sysadmins to block this thing and be peculiar about it having some value... but having the default behavior of the ecosystem change to match this really silly strategy, that is bonkers.

Re:security best practice?

[Junta]

There's process accounting and cgroups to manage the resources used by users, which enable administrators to manage directly the true worry: resource consumption. Tying resource consumption to a connected 'session' still allows the misbehavior you imagine, it just takes even more hoops to keep that session alive.

Re:security best practice?

[Junta]

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

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

Re:security best practice?

[LesFerg]

I don't follow the projects or their members that closely, so I couldn't comment on who is a genius or a lackey. I just know that sometimes a .deb includes some configuration that suits the Debian environment, which you may not get if you download the source and build it yourself. I wasn't trying to preach or anything, hey, sometimes we screw up with the code or the implementation of it, tho I wouldn't have expected the subject matter to have got past testing and out into the wild.

Re:security best practice?

[segedunum]

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.

My mod points have gone sadly, but that sums things up perfectly. The problem here is not killing on logout, it's that even with nohup it is still going to kill them. I mean, that's why you use bloody nohup, and I'm also suspicious as to what other further problems this might cause when you want to run long running processes under a user under other circumstances. Screen is heavily used by administrators, me included.

These things have evolved and are the way they are for a reason.

Re:security best practice?

[Etcetera]

But was this the systemd developers at fault or the person who build the installation package?
It sounds more like a lack of configuration with a .deb.

The systemd developers' stated goal is to "provide gentle nudges" continually to synchronize any downstream users (in this case, meaning distros and users) to their view of what the proper use is; and this has been matched over the years by their actions.

Furthermore, on the Fedora side the Fedora devs have basically abdicated formerly-distro-level decisions like that to "well, upstream has made this change and we want to stay in sync with upstream."

Re:security best practice?

[jbolden]

systemd allow you to have processes not tied to a session. That hasn't changed. You just have to tell the system and have permissions to do it.

Re:security best practice?

[jeremyp]

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.

No it isn't. The ampersand means "run this asynchronously". In fact, specifically, it tells the shell not to issue the wait() system call on the child it has just created. When the login session is exited, all still running children receive the hangup signal, which will normally terminate them. This is standard Unix behaviour and has been since I first started using it, 30 years ago.

Prefixing the command with "nohup" stops the child process form receiving hangup signals which has the effect of allowing the child to survive beyond the end of the session. This is the way it's always been done and any program that alters that behaviour is broken and needs fixing.

Re:security best practice?

[segedunum]

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?

[jon3k]

The problem is the process shouldn't get to decide if they live forever that's the process manager's job.

I don't need the process manager to decide for me how long my processes should run. The computer works for me, not the other way around. If I explicitly tell the computer I want a process to continue running, it should do so.

And ultimately on a shared system you as an unprivileged user likely shouldn't have the ability to run jobs consuming resources for days or weeks directly but rather through operations.

What exactly is this assumption based on? Why shouldn't a user of a system be able to run a process that takes several days to complete? The system admin can easily control the users access to the system resources so that they're shared appropriately. What if it's the only user on the system?

Re:security best practice?

[Junta]

I still fail to see how the ability to have background processes can be credibly described as a security risk in and of itself. It's what resources/actions the process is allowed to do that would be the risk, and any risk a background process poses would also be a risk while a user is logged in.

I'm not arguing that it is impossible in the new way to have disconnected processes, I'm arguing that proponents claiming this somehow enriches security are incorrect.

Re:security best practice?

[segedunum]

systemd allow you to have processes not tied to a session. That hasn't changed.

Slippery political bullshit, which means zilch. Long-standing, expected behaviour has been changed here because lazy morons can't work out why Gnome won't clean up after itself.

You just have to tell the system and have permissions to do it.

Sensible systems allocate resources and allow users to use them. I know of no other system out there that requires you to register every single process type you might want to run beyond a user session so that when you log back in you pick up where you left off. You know why? Because it's fucking stupid.

Re: security best practice?

[buchanmilne]

As the system administrator in a large, complex environment in a larger, more complex organisation, who needs to be sure that users who have left the employ of the organisation don't have the ability to run commands anymore.

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.). This has been a real risk in the past on real servers currently running sysvinit.

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.

Yes, it is configurable, and yes it should probably be set correctly according to some of the installation selections (e.g. enabled on servers, disabled by default on workstations/laptops).

No, just because sysvinit can't enforce it well doesn't mean no-one needs it.

Re:security best practice?

[thegarbz]

You left out the bit where all of this is configurable to the end user. Fuck those guys who give you options because you personally don't agree with their defaults right?

It's almost like we need someone to come up with a sane set of working defaults for a specific purpose. They can combine all the software to do something into one collection, let's call it a distribution, and they can then maintain the distribution with the settings they want to suit their users.

Re: security best practice?

[segedunum]

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?

[ohmiccurmudgeon]

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?

[RightwingNutjob]

Good point. Stop buying from Red Hat and stop using CENTOS.

Re:security best practice?

[BigU 03C0mpin]

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.

I get people being angry about Systemd, change is hard on people and giving up behaviours/knowledge that the community has prided as a point of recognition feels like losing a culture divergence from the Unix philosophy. Unfortunately they're looking at it from the wrong perspective.

The proper perspective is to understand that Systemd is a significant conceptual step towards targeting the enterprise with Linux. This change has made it so Linux effectively now has a centrally manageable remote process control system built in by default. This is an additional level of control over user space processes, which at the enterprise level, is a very valuable feature. Effectively the *nix version of Microsofts "Applocker" in an environment where a user often operates at higher levels of permissions. That's how enterprises operate their networks and a significant step up in securing Linux from that point of view.

Don't dare say sudo in response, great single system low user count idea, but again I'm talking about the enterprise level, hundreds of thousands of servers, desktops and accounts.

Re:security best practice?

[somenickname]

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.

Re:security best practice?

[jbolden]

I think security is probably too strong. I'd say avoids annoyance and operational hassles is probably more fair. So you asking me to defend a position stronger than the one I'm advocating for.

Re:security best practice?

[jbolden]

I think it is pretty obvious the systemd developers are neither lazy nor ignorant. They may disagree with you but those sorts of accusations don't deserve a response.

I know of no other system out there that requires you to register every single process type you might want to run beyond a user session so that when you log back in you pick up where you left off. You know why? Because it's fucking stupid.

Well I'll tell you about one. The longest running popular operating system on the planet: https://en.wikipedia.org/wiki/...

Re:security best practice?

[jbolden]

The computer works for me, not the other way around. If I explicitly tell the computer I want a process to continue running, it should do so.

If you are the admin and understand the issue, change the defaults. The people being discussed either

a) don't understand the behavior they want
b) don't own the system.

What exactly is this assumption based on?

Standard procedures in use for generations.

Why shouldn't a user of a system be able to run a process that takes several days to complete?

In general they shouldn't because it is a shared resource and that's consuming too much of it. Once they start using a shared resource that heavily the activity should be scheduled or they should be using a dedicated or partially dedicated resource.

The system admin can easily control the users access to the system resources so that they're shared appropriately. What if it's the only user on the system?

Yes they can. And if they are doing that they systemd's defaults don't apply.

Re:security best practice?

[phantomfive]

Wow, thanks for that; I always wondered why my nohup processes were dying when I logged out (I didn't know about the ampersand).

Re:security best practice?

[segedunum]

I think it is pretty obvious the systemd developers are neither lazy nor ignorant.

There is ample evidence to the contrary I'm afraid. They continuously break well established behaviour that has worked for a long time not just on Linux but Unix systems and fuck up expected kernel behaviour with userspace.

The accusation here though was that the fix here is to clean up Gnome. To think this is a solution is utterly laughable.

They may disagree with you but those sorts of accusations don't deserve a response.

They don't get a response because they are true ;-).

Well I'll tell you about one. The longest running popular operating system on the planet: https://en.wikipedia.org/wiki/...

ROTFL. Idiot frantically Googles around for something that seems to justify his idiotic claims.

Re:security best practice?

[Junta]

Fair point, I was speaking to this thread, which was calling out forced termination of background processes as a security thing.

Re:security best practice?

[mattventura]

The whole concept of a "session" is needless bloat anyway.

Re:security best practice?

[DutchUncle]

... even if it has been the convention that background processes do stay alive.

Go read the articles about the lawsuits and recalls because a new automatic transmission shift lever design behaves differently from the last 30 or 40 years of convention, and people have been leaving their cars in neutral instead of park, and cars roll unexpectedly. How about making the NEW behavior be the thing that is explicit? You can't even have the system ask you if it's not specified, because that will break scripts.

Please remember that people actually try to get WORK done on computer systems, and don't want them to suddenly be different in unexpected ways.

Re:security best practice?

[Etcetera]

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.

I get people being angry about Systemd, change is hard on people and giving up behaviours/knowledge that the community has prided as a point of recognition feels like losing a culture divergence from the Unix philosophy. Unfortunately they're looking at it from the wrong perspective.

The proper perspective is to understand that Systemd is a significant conceptual step towards targeting the enterprise with Linux. This change has made it so Linux effectively now has a centrally manageable remote process control system built in by default. This is an additional level of control over user space processes, which at the enterprise level, is a very valuable feature. Effectively the *nix version of Microsofts "Applocker" in an environment where a user often operates at higher levels of permissions. That's how enterprises operate their networks and a significant step up in securing Linux from that point of view.

Don't dare say sudo in response, great single system low user count idea, but again I'm talking about the enterprise level, hundreds of thousands of servers, desktops and accounts.

This might make sense if Enterprises were adopting EL7 en masse. They're not. All the fancy newfangled features are meaningless if the system is no longer trustable or reliable, or can't reliably (and deterministically!) boot. And the vast majority of the complexity isn't around resource management, it's dealing with events occurring because Lennart moved his laptop from one coffee shop to another. Enterprises *that* focused on security that some of the new features might be worth it for have already found solutions on EL6 for the most part.

Individually, there are some neat features. Collectively, systemd is a complete and total disaster being guided by a loon with delusions of grandeur who doesn't give a F about anything besides his use case. Enterprise people have seen that kind of thing before and know how unreliable those projects end up being.

Re:security best practice?

[jbolden]

There is ample evidence to the contrary I'm afraid. They continuously break well established behaviour that has worked for a long time not just on Linux but Unix

Disagreeing with the Unix way of doing things and not understanding the Unix way of doing things are not the same thing.

As for the mainframe.... no some of us have used systems that have had to handle contention well for decades.

Re:security best practice?

[Culture20]

Why shouldn't a user of a system be able to run a process that takes several days to complete?

In general they shouldn't because it is a shared resource and that's consuming too much of it.

So if I nice a process out the wazoo so that instead of using 100% of the CPUs for a couple hours while I remain logged in it will now take 72 hours at 0.36% CPUs, that's a *bad* thing? FYI, human time is a precious resource, and requiring someone to hit a space bar every X minutes so they don't auto-logout of their session and kill their hours-long process is a waste of human-time.

Re:security best practice?

[jbolden]

The scenario is a situation where the admin doesn't want processes that take 100% for a couple hours or likely 100% for a couple minutes. 100% for a couple seconds might be iffy but just slip through. If a job is capable of tying up the system for hours it should in most cases be scheduled not run by an end user.

Neither is a bad or a good thing in and of itself its whether the use case fits the admin's (or really the owner's) desired usage for their system.

Nice is a more primitive form of process management. Nice should be absorbed are replaced.

It's still hungry...

[QuietLagoon]

Better feed it. :)

Re:It's still hungry...

[Anonymous Coward]

in Soviet Linux, process kill you.

Just fix the docs...

[msauve]

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

FTFY.

systemd: Repeating past mistakes since 2010

[Anonymous Coward]

Yay! Awesome!

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

Re:Well fuck you, systemd

[Lumpy]

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

WTF

[BlackPignouf]

So, "screen" has always been a good way to ensure that processes don't get killed randomly by disconnections, logout or X crashes.
Then comes systemd and kills all your processes at logout, even when launched with screen.
Finally, then comes Poettering, explaining you that you're a moron if you expect to keep those processes running.
Seriously, the systemd devs make it really hard no to hate them.

Re:WTF

[CRCulver]

If you have a GNU Screen session, then you're still technically logged in, innit?

Re:WTF

[AmiMoJo]

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

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

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

Re:WTF

[AmiMoJo]

My mistake, should be developers'.

Re:WTF

[sjames]

On a reasonably POSIX system, yes. Apparently not in POTTERIX.

Re:WTF

[phantomfive]

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.

Re:WTF

[dwywit]

Seriously, this is stuff we criticize Microsoft for doing - sneaking changes past (or re-setting to MS preferred defaults) without a big "heads up!" for the users.

Let systemd-dev make their changes, but I agree, the distro maintainers have an obligation to put things like this in big, blinking, bright yellow words. I keep my systems up to date, but I don't have the time to follow every changelog.

Re:WTF

[CRCulver]

"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

[aardvarkjoe]

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

Re:WTF

[Anonymous Coward]

There was already an API for this. It was called "signals," and it's an important part of UNIX systems programming. systemd is offering yet another API that doesn't need to exist, but does now, so every package that doesn't want to be terminated in this was will now have to have systemd as a dependency.

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. How much longer before all the standard libc APIs are "enhanced for your protection," and packages only seem to work properly when systemd is underneath?

CAPTCHA: sanctity

Re:WTF

[myowntrueself]

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

Re: WTF

[Bing Tsher E]

Lennart Porttering isn't a head of state with a Secret Service detail, so there are some curious things for us all to ponder.

Re:WTF

[Kernel Kurtz]

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

[nadaou]

You're kidding me, right?

Re:WTF

[Megol]

In the same vein I didn't fuck your mother - yet.

Re:WTF

[JohnFen]

Change, even small changes, has a cost. If the benefit from the change exceeds the cost, then all is well. My problem with this (and I'll admit, this more a "burr in my side" thing than a serious problem) is that the benefit seems slight to nonexistent.

Change is a part of tech, and that's a good thing. But change without compensatory benefit is a bad thing, even in tech.

Re:WTF

[Zaelath]

SSH came with a provable security benefit and didn't silently fail, this change is merely an opinion of best practice and forces a poorly documented change on an unsuspecting public.

Try a better analogy, like "we're doing it this way now because Daddy said so."

Re:WTF

[Gaygirlie]

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

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

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

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

Re:WTF

[Peter H.S.]

SSH came with a provable security benefit and didn't silently fail,

Yes, that is exactly what we told the whining users back in the day when they fiercely resisted to stop using telnet, rlogin and similar old Unix crap.

But some people just have severe trouble adapting to new tech and new work flows and start to cling to old outdated procedures and programs.

this change is merely an opinion of best practice and forces a poorly documented change on an unsuspecting public

But the new defaults really _is_ best practice. Denying that is like denying that ssh is better than telnet.

Re:WTF

[RightwingNutjob]

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

[nyet]

One more time:

"screen" exists everywhere I have screen installed.

"systemd-run" does not.

Re:WTF

[WorBlux]

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"

Re:WTF

[RightwingNutjob]

But the new defaults really _is_ best practice. Denying that is like denying that ssh is better than telnet.

Protip: asserting something a dozen times is not the same thing as proving it. Especially when you're wrong: breaking other people's shit is not best practice.

Re:WTF

[RightwingNutjob]

Change is just part of tech. Get used to it.

Actually, it isn't. Standards bodies are part of tech and have been from the beginning. They exist to keep self-assured solipsists from inventing their own "standards" and selling them to unsuspecting customers.

"Aluminum is the next greatest thing, better than steel, so even though you ordered a steel plate, I'll send you an aluminum one instead. It's my new standard." Let's see how that works out.

Re:WTF

[aardvarkjoe]

But the new defaults really _is_ best practice. Denying that is like denying that ssh is better than telnet.

Asserting that over and over doesn't make it true. Your argument seems to be that "With this change, people can at least ensure that their user run service doesn't DoS the server unintentionally." Which this change doesn't even do.

Re:WTF

[WorBlux]

*YAWN* The design was broken in the first place. There was no way for the computer the tell the difference between an intentionally unresponsive process a inadvertently locked or stubborn process. When things were simply you could give some trust that the applications actually were doing the right thing, now not so much. How would you solve it? You can't control upstream and even if they cooperate it'll take time to patch. If you white-list the most common things you want to keep, you confuse the heck of of people using the next edge case you don't white-list, and seriously violate the seperation of mechanism and policy design principle. Systemd is the one daemon to rule them all. Screen behaves exactly as before, except now the session manager is good enough not to lose track of it. and recognize it as originating from the user session it's trying to manage. All must bow to the one true daemon.

Re:WTF

[RightwingNutjob]

That is just silly.

You didn't answer the man's question or refute his claim. You just called him "silly." Why did you do this?

Ooh, ooh, pick me, I know: It's because you don't have a leg to stand on and the only arrow in your quiver is to label everyone (and it really is everyone) who doesn't agree with you as wrong, or silly, too uptight, or childish, or old, or crotchety, or naive, or by some miracle all of them at the same time.

Here's another protip: Put up or shut up: slick PR and a parade of lies may fly in whatever Trumpistan you're from, it don't mean shit at the coalface.

Re:WTF

[Curunir_wolf]

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?

Re:WTF

[Curunir_wolf]

This isn't about running stuff in the background (though systemd-run can do that too)

It can ! OH! Glory Day! What a miraculous tool this systemd is! YES ! It's a miraculous tool!

Miraculous tool

Re:WTF

[RightwingNutjob]

Took me a while to guess this is sarcastic. But I'll run with your argument to illustrate yet another important point about good engineering: avoiding quiet failures.

Back when you couldn't tell if process unintentionally didn't respond to SIGHUP or intentionally kept running, you could tell if you had a bug by seeing all kinds of copies of your process still running after you closed out your session. You'd see your process table fill up with copies of your executable, and you'd know to look for a bug, or at least to report one.

Now, if the default behavior is to kill everything, you could well have some kind of latent bug that you'd never discover because systemd squashes its manifestation. What was before a conspicuous failure mode (albeit intermittent) is now a quiet failure mode. So now you might not notice the bug until it really bites you in the ass, loses you money, or God forbid: kills people.

Re:WTF

[Curunir_wolf]

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

That is just silly. I suppose you would have fiercely resisted when Telnet was kicked out in favor of ssh too since it had new syntax.

So systemd is changing the behavior of every other program? I still have telnet, and still use it. But not for the same things I used to. But it still works the same way. Installing openssh did NOT change the behavior of telnet. ssh did not kick telnet off my system. I can kick it off if I want to - I sure as hell don't want the ssh (or the openssh installer or whatever) kick off telnet for me.

Get used to it.

No. Hell no. I won't ever get used to some component of any device arbitrarily changing the behavior of some other component. Imagine the death and mayhem if that happened regularly.

Change is just part of tech.

just part of tech.

part of tech.

of tech

of tech

of tech

Re:WTF

[Peter H.S.]

But the new defaults really _is_ best practice. Denying that is like denying that ssh is better than telnet.

Asserting that over and over doesn't make it true. Your argument seems to be that "With this change, people can at least ensure that their user run service doesn't DoS the server unintentionally." Which this change doesn't even do.

Yes it does, because using systemd-run enables you to use resource management on the user run service. See https://www.freedesktop.org/so... for some options.

Also, it really is best practice to totally clean the user session at logout, only allowing explicitly permitted processes to continue to run.

Re:WTF

[dbIII]

Or even better. Start screen automatically at boot by running it as a .service

You see guys - they just don't get multi-user and cannot even dream that a second user may want to use something like screen as well.

That stupid single user MSDOS mentality was obsolete before MSDOS even started and should be kept out of modern systems.

Re:WTF

[RightwingNutjob]

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

[Peter H.S.]

So systemd is changing the behavior of every other program? I still have telnet, and still use it. But not for the same things I used to. But it still works the same way. Installing openssh did NOT change the behavior of telnet. ssh did not kick telnet off my system. I can kick it off if I want to - I sure as hell don't want the ssh (or the openssh installer or whatever) kick off telnet for me.

Oh yes, telnet was kicked off the default installation list along a lot of other inherently insecure Unix stuff like rsh and rlogin etc. Instead you got ssh. People whined about that too; suddenly they had to manually install a telnet client (lets just suppress the memories that some Linux distros came with a telnet-server as default).

ssh dramatically changed the whole workflow on both Linux and Unix, and a lot of people didn't like that. Same with packages and package management (how I don't miss hand patching and compiling). These days it is systemd that changes how Linux work, and I must say I much prefer how it does things as opposed to the old days of SysVinit.

The bottom line is that tech changes all the time, or else it becomes obsolete. That is just the price of progress. Cling to the old ways, and you and your skills become obsolete in the same way.

Re:WTF

[RightwingNutjob]

Cling to the old ways, and you and your skills become obsolete in the same way.

That's what they said about COBOL programmers in the 80's and early 90's. On a completely unrelated note, a large number of COBOL programmers made quite a handsome income around the late 90's.

SSH did not change the workflow. SSH (the new thing) has a way of acting exactly like telnet and RSH (the old thing). And I will remind the arithmetically challenged that installing a package manually is a whole different beast from HAVING TO REWRITE ALL OF YOUR SCRIPTS.

Re:WTF

[Peter H.S.]

Or even better. Start screen automatically at boot by running it as a .service

You see guys - they just don't get multi-user and cannot even dream that a second user may want to use something like screen as well.

That stupid single user MSDOS mentality was obsolete before MSDOS even started and should be kept out of modern systems.

Please be aware that we are talking about user .services, not system .services.
A users services are totally independent from other users services, and the system services.
Each user can control their own services with standard systemd tools like "systemctl start screen.service" and you can employ the whole suite of systemd features like socket activation, AmbientCapabilities, Cgroup resource management, etc. on such services.

I think the systemd developer group is the single most knowledgeably Linux developer group when it comes to multi-user Linux. The very existence of "systemd-logind" is a proof on how much better multi-user Linux work on systemd compared to any non-systemd distro. I mean, running Xorg rootless is only safe on systemd distros.

Re:WTF

[dbIII]

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

[l3v1]

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

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

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

Re:WTF

[Dog-Cow]

Really? No other way? So screen working for all these decades has been happy coincidence?

Re:WTF

[Dog-Cow]

Telnet and ssh are different programs, you incomprehensibly stupid piece of shit. I know you're a troll, because only a troll could be so stupid.

Re:WTF

[Dog-Cow]

Can you actually name a system that at one point stopped shipping telnet by default, replacing it with SSH? OpenBSD does not count, because that kind of change is exactly why OpenBSD exists, and its users would not have been surprised by it.

Re:WTF

[Etcetera]

FWIW, I've only found one quote by Lennart Poettering about the entire thing (source):

I am not sure I follow. Note that user@.service is already reference counted by the login sessions around. i.e. it is started before the first user session of a specific user is created, and stopped when the last user session ends. I don't follow why that behaviour is not sufficient?

Lennart seems to have learned by now to be careful what he says in public, so I don't expect him to call anyone a moron here.

No, there's a similar debate blowing up on the Fedora list as well, it's just that there's hardly anyone left with the energy to fight the cabal any more.

From the Fedora List:

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

...

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

Re:WTF

[Peter H.S.]

Telnet and ssh are different programs, you incomprehensibly stupid piece of shit. I know you're a troll, because only a troll could be so stupid.

Yeah, I actually know the difference between those two programs, and old enough to have used both telnet and see ssh replace it as the default way for connecting to other machines.

People unable to cope with technological changes like the transition from telnet (rsh/rlogin/etc) to ssh, SysVinit to systemd, or the future, Xorg to Wayland, just eject themselves out of tech.

Re:WTF

[phantomfive]

Nice find, thanks.

Re:WTF

[dr_blurb]

On a reasonably POSIX system, yes. Apparently not in POTTERIX.

POTTERIX should just be a separate distro, his own little playground.

I'm still convinced Poettering is on Microsoft's payroll.
"Fight the enemy from within", they told him.

Re:WTF

[tstrunk]

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.

Well, it's a point of view, but not necessarily bad. Both points of view are valid:
Yours is:
a) Assume that processes which stay alive after logout are meant to be there, leading to a potentially unclean state after logout, if some random gnome/kde/etc. process did simply not exit
Systemd's is:
b) Assume all processes, which stay alive after logout are dead leftovers, always provide a clean slate.

Each has their up and downsides and I very much agree that the way the change was introduced was bad, because the release came without warning like a sledgehammer and changed existing behaviour. If screen and nohup were made systemd aware beforehand with a looooong introductory period and many warnings, this outcry would have been much much smaller.

When just looking at both options a) and b) without thinking about existing behaviour, I do think that b) is the better option. When logging out, I expect my system to be in a clean state and I, as a user, will never check for still running processes after logout.

Re:WTF

[goose-incarnated]

But the new defaults really _is_ best practice. Denying that is like denying that ssh is better than telnet.

Silent failures that lose data is never best practice. Ever heard of the Principle of Least Astonishment? No command or UI action should *ever* be changed so that it looks the same as before, but does the opposite action.

Will you change the "Close" menu entry in an application to simply close with no warning to the user about unsaved work? Why do the same thing with screen?

Re:WTF

[shutdown -p now]

Your analogy is hilariously bad.

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

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

Re:WTF

[Barsteward]

of course he gets it. most people get it but feel its too trivial to worry about. You seem to be saying that nothing has changed in the running of unix/linux since the year dot and you've never had to change a script at any time to allow for a change of process.

Re:WTF

[Barsteward]

if tightening up of your system security seems slight or non-existent then fine i.e. i don't see anything wrong in defining what is allowed to remain running after you logout. Yes, its a little more work in the beginning but security is an ongoing process.

Re:WTF

[F.Ultra]

Agreed that this indeed is bad behavior if they try to sneak these changes through. However this issue is at the moment for Debian Testing so we do not know at this point in time how things will look in Debian Stable once v230 ends up there (which probably will take a long time).

Re:WTF

[donaldm]

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.

Ok, I am not running any Debian distribution but Fedora 23 with the latest updates. Here is my test.

1) Fire up screen and run just for the sake of the test top.
2) Detach screen with the command Ctrl-a Ctrl-d (ie. detatch screen).
3) Check to see if the screen process is running using the "ps -ef" command. It is!
4) Now logout of my computer.

Log back into my computer and on the command line run "screen -r" -- does my detached process reattach and is my top process running?

Yes, my process is running which is what I would expect.

If the Debian side has a problem then this needs to be fixed. File a bug report.

Re:WTF

[donaldm]

If you have a GNU Screen session, then you're still technically logged in, innit?

Irrelevant, if you are running a background process that is under your user name you effectively own that process. In the case of running "screen" you can actually detach and reattach that particular process and all child processes attached to it.

Under Fedora 23 with the latest updates "screen" works as it should. Since this problem seems to be under a Debian distribution then it needs to be fixed or, are people just jumping on the "I hate systemd" bandwagon without running some trivial tests.

Re:WTF

[donaldm]

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"

I don't have the so-called problem with Fedora 23 with the latest updates. The "screen" process works exactly as it should. I have detailed my test in a previous post in this thread so I won't bore you with a repeat.

Re:WTF

[Hognoxious]

So systemd is changing the behavior of every other program?

Not all of them. Just the ones that it's not absorbing.

Re:WTF

[donaldm]

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

I question the moderator for marking you as a Troll.

The simple way I use "screen" is to just type "screen" in a terminal window then:
1) Run any processes I wish to run before I log out.
2) Type Ctrl a Ctrl d which detaches the screen session.
3) Logout.
Log back in again and in a terminal window type "screen -r" and your screen session will attach with all processes still running. This works fine with Fedora 23 and it's latest patches. You don't have to fiddle with systemd settings.

Re:WTF

[aaronl]

That already happens. The user shell knows that the user has disconnected via HUP signal, and then passes that signal along to the spawned child processes. If the user ran a process with & or nohup, then the shell knows not to mess with those processes. That is, until systemd comes along, breaks more convention, and just terminates everything anyway, ignoring what the user already told the system. Unless the user specifically interacts in such a way that only works on certain systemd supported operating system variants, running certain versions of systemd, configured in certain specific ways.

The previous and well understood behavior already did this, and it worked on all UNIX-like systems. The new systemd way works on a very small minority of systems, and requires special behavior and a half-dozen special checks to detect environment.

This is not an improvement. This is single-user proprietary behavior.

Re:WTF

[Junta]

there's hardly anyone left with the energy to fight the cabal any more.

You could have stopped at just 'there's hardly anyone left'. Fedora userbase at this point are people happy to be RedHat's unpaid beta testers. If they don't like systemd, they've already retreated to other distros, even if systemd has come to those distros in the interim.

Re:WTF

[Junta]

Note that for one, telnet represented a very real and serious security problem that was actively breaking people.

Note also, that for over a decade, most things that ran sshd *also* ran telnetd, just in case. The community was allowed to embrace this change at their own pace, and if it had been rejected, telnetd would still be running by and large today (there are actually a fair number of scenarios where it's still common to run telnetd). It was a change that allowed choice, not a change that forced itself by changing things.

Re:WTF

[Anonymous Coward]

Now run this test:

1) rpm -q systemd
2) compare the version number with 230, which is the systemd version that implements this change

Is it lower or higher? Yeah, thought so.

Re:WTF

[Junta]

I see no evidence that this does anything to aid security. Users are still allowed to do what they could do before, and they are still prevented from doing things they were prevented from doing before. I would have to see citations for security issues that actually pertained to this phenomenon.

With telnet, there were widespread incidents of folks doing a network sniff and misbehaving. Even then the move from telnet to ssh was by and large pretty leisurely and not forced.

Re:WTF

[Junta]

that is exactly what we told the whining users back in the day when they fiercely resisted to stop using telnet, rlogin and similar old Unix crap.

That was between the admins and the users, *not* between the OS vendors and their customers.

Denying that is like denying that ssh is better than telnet.

I don't see it. Those calling 'security' are crying wolf here.

Re:WTF

[Junta]

Adding to your argument, one thing I absolutely *hate* is when I'm told 'well, just log out and log back in and see if it gets better'. It's a step shy of 'reboot and see if it gets better'. This sort of change is encouraging that behavior. Applications that go off the rails are a problem before they log out. If an application manages to start itself multiple times rather than reuse the existing instance, is a bug. Applications need to be *fixed*, not worked around in an inconvenient manner to the user.

Re:WTF

[Junta]

I agree with your side of the argument, that systemd is nuts and change is only good when it is good, however, I don't think particulary GNU and Linux ecosystem can hold up standards bodies as something that has been a huge active part of defining the ecosystem. POSIX hasn't said anything at all in nearly a decade, and what things it has said have been frequently met with disdain: 'The variable POSIXLY_CORRECT is now also used for a number of other behaviour quirks, where "POSIX and common sense disagree".'

There are certain fronts where standards play (network protocols), but by and large the relationship between OSes and their applications aren't governed by any 'standard bodies' anymore, and so we've seen more and more divergence between popular Linux distros, Windows, OSX, and the BSDs.

Re:WTF

[Junta]

Also we have to think of time scale. SSH first started becoming an option in the mid 90s and first started appearing as a default feature around that time. rsh and telnet were still in most defaults a decade later, alongside ssh. It's only in the past 3-5 years I've noted telnet stop shipping as a client app by default. They gave it *plenty* of time and to this day it's trivial to add it back if someone wants it, and the change is more trivial to implement (symlink ssh to rsh and you are pretty much done to embrace the new)

Re:WTF

[Junta]

Again, you keep trying to bring up telnet/rsh/rlogin/etc to ssh as the same, when it isn't the same. Xorg to Wayland (or Mir) was supposed to happen ages ago, but has not (the developers are being rightfully careful about the relatively huge disruptive change, with a huge emphasis on providing *all* the benefits of what came before it rather than saddling their users with incomplete crap). systemd was flipped over in a heartbeat and is duct taping things left and right as admins are horribly broken by it while at the same time hurling insults at admins for struggling with it. It's not some 'oh, you can use it if you like, or use the old stuff' without changing the OS installed (which is the case for telnet/ssh and for Xorg/Wayland), it's 'take it' with no option to leave it.

Re:WTF

[Junta]

Also, ssh and telnet coexistence was trivial and the rule of things for a very long time, despite the relatively minor seeming reality of changing to use ssh over telnet, and continues to be available for those who want.

Re:WTF

[jon3k]

It has been discussed for ages now among many OS people

Who? Where? Who are these "OS people" ? The screen/tmux programs and the nohup command was literally invented to take advantage of this behavior to allow long running processes. We've used them for decades. There is no "problem" here. There's nothing to "solve" or "fix". Nothing is wrong!

Re:WTF

[RightwingNutjob]

Except you can't make the same argument. If you crap over another process, you get a SIGSEGV and an entry on both the terminal and system log telling you you screwed up. Not a quiet failure.

Re:WTF

[jon3k]

You're comparing a system changing the behavior of one program with distributions replacing one program with another. This is not a good analogy.

Re:WTF

[thegarbz]

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.

So why start now? The way I see it systemd provides this as a configuration option and the Debian distribution should have known better than to let it be set given their server oriented distribution. On the flip side someone with a desktop would benefit from this change.

What systemd has done is made it configurable and everyone shits on it because their favourite baby distribution has the wrong default set. boo-hoo.

Re:WTF

[sconeu]

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?

Re:WTF

[WorBlux]

Only half sarcastic, the systemD guys really do want to manage, track, and expose control levers for just about everything that happens between startup and shutdown. To paraphrase, to create a standard Linux plumbing system that distros shouldn't have to mess with too much, and third party vendors can rely upon to behave consistently across various systems. .

Re:WTF

[WorBlux]

No, it was a dirty hack more or less. It relied on the user to determine after the fact as to weather programs that escaped were misbehaving or not and report the bug or patch accordingly. However systemD isn't an intelligent user, it's a blind program following unequivocable rules, there's no way for it to tell the difference categorically. Yet, there is good reason for systemD to terminate misbehaving processes, which it can't tell apart for from screen's dirty hack dating back to a venerable, but not perfect UNIX operating specification.

Re:WTF

[phantomfive]

Yes, that is exactly what we told the whining users back in the day when they fiercely resisted to stop using telnet, rlogin and similar old Unix crap.

I don't know about that, in the groups I worked with, all the users were happy to move to ssh once they learned how cool it is. Ssh seemed like a step up in every way, and I'm still happy to use it.

Re:WTF

[JImbob0i0]

Note that systemd-230 has only just been released so it's only arrived in Rawhide.

Fedora 24 will still ship with systemd-229

You can switch to this behaviour by changing your logind.conf on F23 or F24 but obviously that won't entirely act as systemd-230 since it won't have the same code path.

The question has been raised about this being adopted in F25 and no doubt FESCO will have to make a decision as a system wide change.

There is a reasonable likelihood this default behaviour in Fedora will be rejected - or at least only in the Workstation product with the Server product maintaining the old behaviour.

Re:WTF

[Anil]

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

That is just silly. I suppose you would have fiercely resisted when Telnet was kicked out in favor of ssh too since it had new syntax.

Change is just part of tech. Get used to it.

Your given analogy is bad.

Telnet is a program that still exists today, and still works like Telnet. When SSH became the standard, programs using Telnet did not break; software using Telnet did not need to be re-coded immediately due to an OS update. Programs using Telnet still work today.

Re:WTF

[anyGould]

In my view it was actually quite strange of UNIX that it by default let arbitrary user code stay around unrestricted after logout.

Hell, I'm no guru but I know the answer for this - it's so you can run long tasks without having to tie up a limited terminal in the lab. Log in, start your task, log out and go for beer while someone else gets use.

Now, in this world of "everyone has their own computer and terminal", it's not as necessary a feature as it used to be. But that hardly seems a reason to arbitrarily flip the default.

Re:WTF

[RightwingNutjob]

Read again. The fact that it kills the process masks the error. If it did something semi-intelligent like sending SIGKILL only after SIGHUP failed to terminate the process and logged that fact, then it's not silent. But that's not what we're talking about.

Re: Well fuck you, systemd

[ArmoredDragon]

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

[Noryungi]

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

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

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

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

Re:To be quite honest...

[AmiMoJo]

The real problem is that there is no good alternative. The old init systems are creaking under the weight of many patches, scripts and hacks. Even the BSDs are looking for a good replacement to their old systems. systemd is just the best of a bad bunch, and to be fair it does provide solutions to a number of issues.

The only way to combat systemd is to build something better. Fork it, or just start from scratch, but offer something that fixes the issues that systemd addresses, particularly the prior lack of common APIs for many seemingly simple management tasks.

Re: To be quite honest...

[Bing Tsher E]

For some reason that translates in my head to Donald Trump saying "It's rickety, it's old, let's tear the whole city block down and I'll build a shining new office tower there."

Young punks always think they know best when they're tearing out the insides of things they don't really understand.

Re:To be quite honest...

[Megol]

I can tell you never programmed a computer. Patches software accumulates cruft unless periodic cleanups are done. Doing cleanups tend to create bugs. Rewriting code should use the experience from developing the original system - given a competent programmer or team of programmers.

Re:To be quite honest...

[Waffle Iron]

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

[Waffle Iron]

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

[Peter H.S.]

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

I think it is rather a question of who first "stole" the nice short commands, leading to permanent hogging of the namespace. Who is really using ar these days.

Anyway, those "terse" commands and their "terse" switches are really hard to remember, especially when they only have the vaguest mnemonic resembles to what they perform. And "-t" can mean anything depending on what program it is used with.

The solution was to use proper mnemonic commands and have tab completion of everything, including switches, and always have "long option" switches so a simple "--*tab*" would reveal the options. This combined with using the command stack is highly efficient, not only when it comes to typing, but also when it comes to remember what stuff do.
Programs like git and systemd is designed around this concept. I like it.

  to support a misfeature that has no benefits to me.

I think we can safely assume here that do don't really have any experience with systemd-run, nor have actually read its man-page. So you must have psychic powers in order to know that it offers no benefits to you.

Re:To be quite honest...

[Waffle Iron]

Oh gee, multiple pages of documentation to achive the equivalent of:

$ cmd &

But it's all worth it, because now my background command is a frigging "service"! I always wanted to create my own service! I'm doing really important stuff now!

Re:To be quite honest...

[nyet]

"nohup" exists on every machine.

Your "systemd-run" twaddle does not.

Re:To be quite honest...

[nyet]

"telnet" is exactly the same length as "rlogin"
And always forced you to type your username and password.

"ssh" is 3 characters SHORTER than "rlogin".

Re:To be quite honest...

[swillden]

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

Why are you blaming systemd for having an optional feature that you don't happen to want? You should be blaming Debian for deciding that this feature is one that everyone wants by default. We can debate whether or not systemd should have this option, but the real question is why Debian thinks it should be turned on for everyone.

Re:To be quite honest...

[dbIII]

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:To be quite honest...

[Peter H.S.]

> Anyway, those "terse" commands and their "terse" switches are really hard to remember

No, only for clueless morons like yourself.

A rather typical response from you. Please learn to argue if you want to be taken seriously.

Re:To be quite honest...

[mvdwege]

the reality can be seen in those distros and operating systems that do not use SystemD and are not "creaking"

So tell me, just how do you keep track of a started service, to verify that it is indeed running and to shut it down cleanly? If you have any better solution than pidfiles, I'd love to hear it.

And yes, that is one of the things that systemd solves. I may not always agree with the default settings chosen, but systemd exists because there are good technical reasons for something like systemd to exist, and the systemd devs are apparently the only ones who don't stop at whining but actually code. So long as the haters do nothing but whine, you will have to put up with Pottering's insights and foibles.

Re:To be quite honest...

[Barsteward]

RTFM before you jump

Re:To be quite honest...

[Barsteward]

that's your problem, you stopped reading long ago to stay in your comfort zone.

Re:To be quite honest...

[Barsteward]

You live in the Utopia of the coding world.

Re:To be quite honest...

[Barsteward]

screen does work as before.... if you are that lazy, use your scripting skills and create a script with a name of one character in length to launch screen. i can't believe the trivial excuses that ooze their way out of the woodwork.

Re:To be quite honest...

[Barsteward]

whats your problem? learning new things a bit daunting?

Re:To be quite honest...

[donaldm]

"nohup" exists on every machine.

Your "systemd-run" twaddle does not.

Fedora and Redhat would like a word with you. Personally, I have never used systemd command line programs but they do exist..

If I want to run a job and log out I would use "screen". If your "screen" processes get killed when you log out it is not the fault of systemd but possibly a flag in the /etc/systemd/logind.conf file. If you see #KillUserProcesses=yes then as the system administrator you should change it to #KillUserProcesses=no. Of course in a commercial development, testing or production environment, you better get permission to do this and raise a change request to cover yourself.

Re:To be quite honest...

[dbIII]

With respect, if this example wasn't enough to show that SystemD is held together by the equivalent of duct tape then there are plenty more.
It's rushed, is a fast changing moving target and has not yet got to the point where it can compare well to similar systems that preceded it. I have to disagree with the speed claims at this point and you may have noticed that the developers that initially claimed they would have vast speed improvements have become very quiet on that front. It turned out not to be as easy as they thought when they actually got around to doing it.

Re:To be quite honest...

[Etcetera]

the reality can be seen in those distros and operating systems that do not use SystemD and are not "creaking"

So tell me, just how do you keep track of a started service, to verify that it is indeed running and to shut it down cleanly? If you have any better solution than pidfiles, I'd love to hear it.

And yes, that is one of the things that systemd solves. I may not always agree with the default settings chosen, but systemd exists because there are good technical reasons for something like systemd to exist, and the systemd devs are apparently the only ones who don't stop at whining but actually code. So long as the haters do nothing but whine, you will have to put up with Pottering's insights and foibles.

Wrong. pid files and subsys locking worked and continue to work fine for the vast majority of cases. CentOS 6 / RHEL 6 is still super-widely deployed and many enterprise shops are delaying moving to EL7 (when they otherwise might be right around now) specifically because of systemd and a few other changes. Somehow, we're managing to run a modern system without using systemd... Crazy, I know!

For those that *do* need a service manager, there have already been solutions written for it. I use daemontools personally, but other people have different tools. The point is: Almost nothing that systemd does with regards to service launching couldn't be (and isn't already) done with some combination of "normal init scripts", xinetd, and daemontools. It's one true nifty feature in that area is automatic cgroups management, but frankly that feature alone is nowhere near worth the hassle of dealing with all of the other crap they're doing.

Re:To be quite honest...

[mvdwege]

pid files and subsys locking worked

Oh sweet summer child, you really believe that?

Re:To be quite honest...

[RightwingNutjob]

Right back atcha! Telling people they're wrong because they know what they're doing and you're too lazy to learn what they're doing therefore you're right is not an argument, it's a temper tantrum.

I'd like to see you driving a car in traffic: my traffic laws are more sensible than yours, so I'll just expect you to follow my rules of the road and blame you when there's a crash.

Re:To be quite honest...

[thegarbz]

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"

You mean those niche distributions which are slowly dying out of irrelevance? It is no secret that all the popular distributions were working on a replacement to init. SysV-init worked... just, and with effort. That's the only praise it gets. I mean shit we've been running alternate daemons that have handed off the job init wasn't able to do for a good 20 years now leading to a case where the init system wasn't even sure what the hell daemons were running anymore. It was garbage then, but it's only considered amazing now that someone has actually produced an alternative that more than one distribution has adopted.

Re:To be quite honest...

[dbIII]

Don't have to believe, can see it in action.

Re:misleading title as usual

[Nikademus]

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

Re:I assumed this was already a default

[Anonymous Coward]

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

You're an idiot.

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

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

Re:Well fuck you, systemd

[whoever57]

Or Gentoo. systemd is optional on Gentoo.

Re:I assumed this was already a default

[hviezda14]

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:I assumed this was already a default

[Midnight Thunder]

Wouldn't it be better to save state on logout and restore on login? This would provide the balance between saving system resources and allowing a user to start off where they left off. Of course applications would need to be aware of state saving. Is there already some sort of API for this?

Re:Well fuck you, systemd

[F.Ultra]

So what you are saying that you not not expect BSD Unixes to let ill behaving processes to linger after you log out but that you also see this as good behaviour? Not sure that the developers of the various BSD Unixes agree with you there.

Myself, I expect that such processes gets killed. I also expect the default of this value to be set to "no" on the various server editions.

Re:From a security perspective...

[silas_moeckel]

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

Re:I assumed this was already a default

[spire3661]

Isnt that for the ADMIN to decide?

Re:I assumed this was already a default

[Anonymous Coward]

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

Re:I assumed this was already a default

[AmiMoJo]

This is indeed a weakness of pretty much all current Unix systems. It is slightly mitigated by having per-user limits on stuff, but basically if someone opens a screen session and runs yes the machines's CPU will generate as much heat as possible indefinitely. malloc() a few gigs of RAM for good measure.

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

[Anonymous Coward]

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

Well, the reality is that neither is sufficient.

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

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

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

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

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

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

egotistic breakage charisma

[epine]

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.

Systemd-OS

[k2r]

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

Don't worry, Systemd-OS will implement process accounting, soon.

Isn't that what SIGNUP is for

[Anonymous Coward]

If I nohup a process then I want it to persist. Why invent something different when that still works fine?

Re:misleading title as usual

[F.Ultra]

It however have to be said that just because v230 of systemd have changed "#KillUserProcesses=no" into "KillUserProcesses=yes" in /etc/systemd/logind.conf does not mean that distributions will ship with this. v230 have just hit Debian testing so it will be quite a while before it hits Debian stable.

Re:I assumed this was already a default

[Anonymous Coward]

What about when I have a long running process I need to run and I don't want it to be stopped if I get disconnected from wifi? Or maybe I know it'll still be running when I have to go home?

The way it is now, if I just disconnect from ssh, they get killed. If i go out of my way to ensure they won't (e.g. start them in a screen session) then they aren't. How is the old way a problem?

speak of the devil

[epine]

Why does Google Maps on FreeBSD default to lite mode?

I was just using Google Maps, and it reminded me that on PC-BSD (both Chromium and FF) Google Maps only runs in Lite mode, despite having all the requirements.

You can fix this by spoofing your user agent string to an older browser version. As stated, PC-BSD rocks, but it's by no means a panacea (though no great fault of their own).

-1 Google web coders

Any Poettering haters out there who know someone who works at Google, please put the word out that this is not acceptable.

A total non story ..

[khz6955]

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

Re:A total non story ..

[Anonymous Coward]

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

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

Re:A total non story ..

[Guy Harris]

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

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

Re:A total non story ..

[nyet]

If that were the *default*, it would be a non-story.

Re:A total non story ..

[Barsteward]

no it isn't. you are moaning from a a point of ignorance. RTFM first.

Re:A total non story ..

[andremerzky400]

It might be the year of the linux desktop, but I for one do not have root access on the majority of boxes I work on -- so now I will have to chase each individual admin to get screen working again. And explain to them why the have to deviate from default settings. And 'security' popping up on the first google search on why that default now exists. Thanks very much, I am looking forward to wonderful discussions about non-default security settings on machines for which I need to jump hoops to get on in the first place... :/

Re:A total non story ..

[RightwingNutjob]

Is he also the lead user?

Re:Rapists

[stooo]

Systemd is a pain.

Re: misleading title as usual

[slack_justyb]

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.

Re:misleading title as usual

[the_B0fh]

Who's bitching about debian? No one.

Who's bitching about systemd's insanity? A lot of people.

Who's concentrating on things hopefully working in debian stable? You.

Re:I assumed this was already a default

[sjames]

No, it wouldn't be. First, if you will contemplate what is involved in saving state, you'll realize what an incredible challenge it would be to do so perfectly every time in every case.

For example, if I start a slow FTP session, how will the magic state saver cope? Remember, the remote server is not taking part in the state saving.

Second, had you done that, wouldn't you be a bit disappointed to find out 24 hours later that the file transfer has made no progress at all?

Screen, nohup, and friends exist explicitly to allow a terminal session to dettach and re-attach as needed. I use screen all the time, especially where a firewall might time out.

It's probably best for the system to work like it's always worked. If they want Potterix to work differently, they should put out a distro.

Re:I assumed this was already a default

[WaffleMonster]

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.

How does this have anything do with management of allocation of resources to users? Isn't an interactive session just as capable of "consuming resources indefinitely" as a running detached process?

If you wanted to stop or limit all of a users processes don't you have that same ability regardless of whether attached to a session or not? I don't understand the logic or benefit in changing a behavior that already requires a fairly specific expression of intent.

It's all Gnome's fault

[the_B0fh]

Apparently, according to some reports, this came about because Gnome can't properly kill off all your sub processes when you log out.

So, systemd to the rescue. Why is anyone using gnome again?!

Re:It's all Gnome's fault

[somenickname]

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

[JohnFen]

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

Re:It's all Gnome's fault

[AFCArchvile]

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.

Re:It's all Gnome's fault

[mvdwege]

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.

Re:It's all Gnome's fault

[Barsteward]

I use KDE and if i log off and use another user, i can still see processes from my previous user session. So its more like these process don't obey the commands to shutdown properly.

Re:It's all Gnome's fault

[mvdwege]

Yes, apparenty because that single source is the only one willing to work on these kind of infrastructure problems. The rest of the entitled little manbabies just go "WAAAAH! WE DON'T LIKE THEIR SOLUTION!!!".

Re:It's all Gnome's fault

[iwbcman]

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:It's all Gnome's fault

[BlackPignouf]

poorly written stuff like PulseAudio

Fun fact : PulseAudio was written by Poettering.

Re:It's all Gnome's fault

[the_B0fh]

Then it's a bug in design or in writing that software. Why should the behavior of the OS change to make up for the bugs in your design/software?

Re:It's all Gnome's fault

[suutar]

actually, it's still not shutting down properly. It just gets forcibly killed when you log out, so the final result is the same and it's all good, right? No longer a significant problem so pulseaudio doesn't have to get fixed?

Re:It's all Gnome's fault

[Agent0013]

And wasn't that badly written PulseAudio also done by Poettering? I think I see a pattern here.

Re:I assumed this was already a default

[CanadianMacFan]

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

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

Systemd always leaves my sessions open

[Anonymous Coward]

They are far too dirty to touch, let alone clean up.

Re:I assumed this was already a default

[sjames]

Do that all you want on a desktop. On a server, perhaps nobody cares or perhaps the admin will kill your processes. Keep in mind, if you don't actually touch the pages your allocation only exists in theory. If you do, it'll get swapped out if you don't keep touching it periodically.

Once it becomes obvious you're burning resources for fun, the admin will either drop your ulimits down or terminate access.

I run a few systems where the user is expected to start simulations that may run for weeks. I don't need something to start mysteriously killing those processes off.

Re:From a security perspective...

[Peter H.S.]

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:Sorry, Slackware is NOT an option. Nor is Gento

[sjames]

Give Devuan a spin. It is very much like Debian but without systemd.

Re:From a security perspective...

[Guy Harris]

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:From a security perspective...

[sjames]

My laptop is connected to the TV. I use it for playiong videos, audio, and various web videos. I don't want anything terminated unless I explicitly terminate it. So they're wrong even in the case of laptops.

Re:I assumed this was already a default

[lucm]

How is the old way a problem?

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

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

Re:I assumed this was already a default

[bbelt16ag]

This is why we tune the systems so that user joe doesn't bring down Susans apps too.

Re:misleading title as usual

[Peter H.S.]

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.

Re:Not a fan

[Anonymous Coward]

Just like Martin Pitt... I quote: "I've long wanted to enable killing leftover processes on logout. In my world, that's what I actually expect when I log out of a computer, and I *don't* want anything running as my user any more (which in turn keeps my encrypted home dir unlocked too). I never got around to enabling the option, but the upstream change was a welcome nudge to actually enable this. I believe this *is* it the expected thing to do on personal computers. This is certainly different in environments like universities where one often does put long-running stuff in the background, but this doesn't appeal to me as being the behaviour to optimize for. At the moment I'm not sure whether this bug report and the followups are just a vocal minority or somewhat representative of Debian's user (I lean towards the former).

However, this really shouldn't be such a general problem: If/when we can change tmux and screen to use PAM or enable lingering, then I think we get the best of both worlds: Logging out would clean up properly, but the (relatively few) users who use screen/tmux on a PC would get the expected behaviour of those processes surviving. So I'm fine with reverting to the previous behaviour until a more fine-grained API (https://github.com/systemd/systemd/issues/3382) is available. Michael, WDYT?"

So because this idiot can't configure GNOME properly he decides that the entire world their servers needs to stop working properly.... and that screen/tmux should be reimplemented!?

Re:I assumed this was already a default

[turbidostato]

"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

[Anonymous Coward]

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

Pure Insanity

[somenickname]

Changes like this make me wonder if the systemd developers even use Linux beyond their local development workstations. This isn't just an inconvenient change, it breaks the expected and decades old behavior of how Unix machines work. This breaks ^Z/bg/disown, it breaks screen, it breaks nohup, etc. Yes, these things can be made to work still but, why do I need to jump through hoops to re-gain the functionality I've relied on for decades? If I'm not aware of this change, how would I even figure out why all my screen sessions died when I logged out? What benefits am I gaining by having this be the default behavior?

Re: Pure Insanity

[Bing Tsher E]

It's almost like a five year old came into the room carrying a hammer. Everybody is uncomfortable saying anything about it and the kid's mom asks "Did any of you bring anything breakable?"

Re:Pure Insanity

[ADRA]

Did you install systemd from source? No, you install it from your distribution. Are they going to install with the feature on or off? Why are you suddenly spurned by the default behaviour of something trivially overwritten becoming the default? If its a dumb change, all distro providers will ship it off by default and nothing of value was lost.

Re:Pure Insanity

[Anonymous Coward]

fuck off, the morons deciding default behavior in your distro are the same morons who adopted systemd on the first place

Re:Pure Insanity

[somenickname]

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

[swillden]

Changes like this make me wonder if the systemd developers even use Linux beyond their local development workstations.

Right sentiment, wrong target.

Oh, I suppose it seems odd that systemd is offering such a feature. I guess there are some contexts in which it may make sense, so perhaps there is justification for it. But merely having the optional feature doesn't imply that systemd developers are insane or clueless.

No, the insane/clueless here are the Debian developers who are deciding to turn this feature on by default. The insanity is in deciding that this behavior is what everyone wants, not in providing it as an option.

Re:Pure Insanity

[somenickname]

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:Pure Insanity

[Tablizer]

No, the insane/clueless here are the Debian developers who are deciding to turn this feature on by default. The insanity is in deciding that this behavior is what everyone wants

When you pick a default setting, you have to make a guess about what users and/or software designers want. Without expensive surveys, that's not necessarily an easy decision.

Re:Pure Insanity

[Barsteward]

RTFM and you'll find the solution. Basically, you configure the things you want to stay running explicitly so a little config is required to set that up then at least you know what is still running are logout is designed and permitted to be running. its tightening up your security.

Re:Pure Insanity

[houghi]

I doubt that. Then they would not do that.

I log in remotely via ssh and use e.g. 'screen'. The reason I use screen is that if I log out (e.g. if connections are lost when I am on the train), it still runs. So here a real life situation:
I log in over ssh and start to do whatever I do from the train. There is one tunnel where I lose connection. I reconnect. I get home and log in and take over the screen session. I close the terminal and I expect the screen session still to be running. Now I log out and the screen session closes, while I expected it to keep running whatever I had running in the screen session.
Fuck you very much.

It is a bootloader. Keep the fuck away of anything else. Cunts!

Re:Pure Insanity

[Entrope]

It is not "tightening up" security. There was already a little configuration step that made things work as desired. "nohup" was one way to do that, but processes could also do autonomously. Why do systemd tools keep wanting to break things that work?

Re:Pure Insanity

[Etcetera]

Did you install systemd from source? No, you install it from your distribution. Are they going to install with the feature on or off? Why are you suddenly spurned by the default behaviour of something trivially overwritten becoming the default? If its a dumb change, all distro providers will ship it off by default and nothing of value was lost.

Their stated goal is to subsume the the distro's decision-making process by continnually nudging them to their preferred defaults. "Harder and harder to use things the wrong way", IIRC.

Re:Pure Insanity

[thegarbz]

What benefits am I gaining by having this be the default behavior?

Ask the Debian maintainers. After all it's their job to decide default configurations to suit their users and their distribution.

The reason for the change is cgroups and APIs that isolate user processes. Systemd was basically born to support this approach. Eventually this would have to become the default option. For that you can blame Google.

Re:Pure Insanity

[swillden]

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.

The Debian guys don't have to "stand up"... all they have to do is uncomment the "KillUserProcess" line in logind.conf and change it to "no". I can give them a sed one-liner if they need it.

Re:Pure Insanity

[swillden]

Actually, it's even easier than editing logind.conf (which requires a patch file or an editing script); all they need to to is add --without-kill-user-processes to the configure invocation in the dpkg build script.

Re:Pure Insanity

[Etcetera]

They do not dogfood Linux on their desktops.

They log in remotely via SSH running on macbooks...

No, it's actually the opposite, which is quite a bit worse.

They only dogfood their shit on their [macbooks]... And the occasional virtualized cloud container bollocks. In short, they're thinking ONLY in terms of a Developer, and a specific type of systems administration that basically consists of hard-coding their administrative decisions into code. Well, bully for them. Congrats on making their own specific, unique use cases work better for them. Unfortunately, they're so full of themselves they don't think any other use cases matter. If you're not doing it this way, You're Wrong... no matter what you've been doing previously.

Re:Pure Insanity

[BitMan]

Changes like this make me wonder if the systemd developers even use Linux beyond their local development workstations ... cut (various "not how UNIX works)" cut ...

Ahhh yes, the common response, that systemd is for desktops. Sigh, for those in Red Hat who saw customers deploy Cluster Suite just to monitor services *and*, more importantly, resources (something Upstart doesn't do) for standalone, single system services, systemd does far, far more for servers than desktops. This is yet another. Customers not only desired systemd, but even the Debian vote exposed how many *major* (thousands of servers) Debian userbases wanted it too.

As someone who has extensive experience with LTSP and RHEV VDI, this was a long, requested change. Because multiuser environments absolutely need this. But ignorance is most common, especially those who haven't worked in 10,000 user Linux VDI environments, which is why get these types of responses. Same goes for the prior on PulseAudio, when the issue usually wasn't PulseAudio, but Ubuntu -- especially off-shoot, non GNOME/Unity Ubuntu -- integration issues.

As far as "how UNIX works," people should really change that to "how BSD works." Virtually all other UNIX implementations *do* have something with many systemd features and approaches.

Re:From a security perspective...

[laddiebuck]

But please.
WHY. THE. FUCK. break decades of well-established Unix conventions? Why the actual fuck?
I hate the arrogance of the systemd folks who think they are doing everything better. Even Darwin respects Unix conventions more than systemd. And yes, they scrapped sysvinit too. And yes, I still prefer sysvinit.

Re: I assumed this was already a default

[Bing Tsher E]

Same as it ever was.

But we have also always been able to identify and route around said phenomena.

Linux has been very successful and it's always true of highly successful projects/companies that they attract certain types after awhile.

The real reason they're changing the default

[Anonymous Coward]

One of many systemd bugs is that it sometimes leaves user "systemd" processes running even after a user logs out. Over time this can add up to many lingering user "systemd" processes. I've seen dozens of simultaneous, buggy user "systemd" processes lingering fter users have logged in and out a few times. The processes have to be manually killed. Rather than fixing the problem they've apparently "worked around it" by kill all login processes instead. This did not occur pre-systemd.

Re:I assumed this was already a default

[Guy Harris]

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

The Unix Time-Sharing System has allowed that since Day One.

The question then is whether we should start treating that as a deficiency to be fixed, and in what ways it should be fixed, e.g. "should even nohupped jobs be killed?"

Re:I assumed this was already a default

[tburkhol]

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

Re:From a security perspective...

[turbidostato]

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

No, the slight change in syntax is not a big deal. That you think changing behaviour for the sake of it is not a big deal, *is* the big deal.

Re: Well fuck you, systemd

[Bing Tsher E]

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

Re: From a security perspective...

[Bing Tsher E]

You're forgetting that all the mac users climbed aboard what they thought was the UNIX bus a little over a decade ago.

Re:From a security perspective...

[fnj]

A thousand times this. Once again Poettering with systemd is "fixing" things that WEREN'T NEVER BUSTED DAMMIT making up new trendy fad ways to do things.

Re:I assumed this was already a default

[sjames]

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

[Ken D]

You have no idea what you are talking about.

screen is a program that explicitly survives logging out and let's you reconnect later. It's the pure terminal version of vnc.

How many "multi user" systems are left anymore anyway? Practically every machine I log into these days is dedicated to my personal use. Just because I've logged out doesn't mean that it isn't supposed to still be working for me.

Re:Well fuck you, systemd

[fnj]

So what you are saying that you not not expect

Perhaps you would like to rephrase that? Because it's unintelligible gibberish the way it's written.

Re:I assumed this was already a default

[Anonymous Coward]

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: tmux and screen

[Anonymous Coward]

Yes, unless you start the processes with a systemd-specific incantation.

Apparently they had never heard of nohup.

Re: misleading title as usual

[myowntrueself]

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.

Re: misleading title as usual

[Peter H.S.]

Correct. Rewrite everything in the past to accomodate our New Leader. All scripts, all startup commands. Shake it all up because the new Briteboys said so.

Oh, Hyperbolic twaddle instead of technical arguments. Hardly surprising.

Re:I assumed this was already a default

[sjames]

Absolutely not. The job is running on the behalf of the user and should one go sideways, I need to know who to email about it. There is often more than one running at a time. Furthermore, they set up the data beforehand so it is owned by them and they will be the ones performing the post-analysis, so they need to own the output files.

Some run the jobs under screen, others prefer nohup.

In a larger group, there would be disk quotas to consider as well.

Re:Sorry, Slackware is NOT an option. Nor is Gento

[Anonymous Coward]

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

[JohnFen]

I don't know about him, but I have several machines that are only used by me that I log into and out of frequently, mostly because I'm doing so in different ways and from different places.

Re:I assumed this was already a default

[JohnFen]

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

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

Re:I assumed this was already a default

[Ken D]

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

Re:I assumed this was already a default

[slashrio]

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

If that 'unprivileged' user is on the sudo wheel, then why not?

Re: Well fuck you, systemd

[drinkypoo]

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

Perhaps there is a happy middle ground. It's a fact that a super-cheapass PC these days can run a whole bunch of virtual machines each more powerful than a PC of not that long ago. If you have anything that makes enough fan noise to bother anyone, then it's probably past time to let go of it for a whole bunch of reasons.

With that said, I'm still dragging an Amiga 1200 around

Re:I assumed this was already a default

[Anonymous Coward]

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:From a security perspective...

[drinkypoo]

But instead of using "nohup /program/ &" you use "systemd-run --user -scope /program/".
So a slight change in syntax, not a big deal IMHO.

Because I use Unix and not Windows for servers, I expect scripts I wrote ten or twenty years ago to still function without changes. This particular problem could probably be solved by simply adding a wrapper script, but a) that's obviously something that should come with systemd and not including it is irresponsible, and b) making this the default is also irresponsible.

Re:From a security perspective...

[gumpish]

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

Shouldn't that read: "Disclaimer: verified using hacked OS image in an unsupported environment, your mileage may vary."?

Re:From a security perspective...

[RightwingNutjob]

You're an idiot. The name of the command is part of its functionality. If systemd were to insert itself in front of the bash interpreter and swap around 'rm -rf' and 'ls -lh', while preserving the 'functionlity' of one under the name of the other, who would need to be jerking you off under the table for you to claim that nothing has changed, and 'it's not a big deal, IMHO'?

Re:I assumed this was already a default

[Peter H.S.]

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?

Re:I assumed this was already a default

[ADRA]

Well to be fair, Alsa was a heaping pile of crap for the things that pulse has been soo much better as (user shared media, splitting, per device mixers, etc..). Alsa is great for what it is: a high level sound card device driver. Hardware doesn't have a feature? You're forced to jump through the moon with pseudo-devices up the wall all manually to get shit to work. I love Alsa and it works for what its good for, but it certainly wasn't a tech stack that played well with modern end-user sound interaction expectations.

The pulse hate (of which I certainly spewed heavily at the time) was almost entirely due to flakiness. They added the kitchen-sink into pulse, but it was really really hard to configure, flaky, horribly latent, and just ultimately not ready for production. The the technology abstraction was exactly what they needed, but the polish wasn't.

How does this relate to systemd? Not much, but I'm sure there will be a storied history written about it. Everyone in the distro world seems to be embracing it. IMHO I don't give a fuck as long as I can write an init script which is run by something at some point to do something init'y.

Sorry but that's the normal behavior

[hcs_$reboot]

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

Re:Sorry but that's the normal behavior

[Guy Harris]

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:Sorry but that's the normal behavior

[hcs_$reboot]

That was "nohup", indeed. An options can take care of the "Exception" - or change to System V.

Re:Sorry but that's the normal behavior

[hcs_$reboot]

mysql is started by root and setuid(mysql) ... the mysql user doesn't log in, the others neither... wtf are you saying?

Re:Sorry but that's the normal behavior

[Cesare Ferrari]

So please explain what the expected behaviour of cron is? Do my jobs start only if i'm logged in - is that the idea, or is cron 'an exception'?

Re:Sorry but that's the normal behavior

[hcs_$reboot]

cron jobs are not affected by the new behavior.

Re:Sorry but that's the normal behavior

[jon3k]

If you think using screen/tmux is an "exception" then you have no business being involved in this discussion.

Re:Sorry but that's the normal behavior

[Cesare Ferrari]

Sounds rather confusing then.

Re:I assumed this was already a default

[Guy Harris]

If you still have the screen up, you didn't log out. By default, all Unices have had it default that a logout causes termination of your scripts. Unless you're root or have something that keeps your session active (eg. the screen command if your admin allows it).

Or you nohupped whatever you ran.

If systemd is using anything other than SIGHUP to kill the jobs, it's not allowing nohupped jobs to continue to run, and may also break other programs as well.

Re:From a security perspective...

[RightwingNutjob]

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

[LVSlushdat]

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.

Re:Makes sense ... but ...

[Guy Harris]

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

[inode_buddha]

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.

Re:Slack FTW

[jbolden]

RedHat is a corporation fighting for licensing fees in enterprise and cloud. They are supportive of the Linux base but not enough to endanger the people who pay them.

Re:Slack FTW

[inode_buddha]

They are definitely playing to the large enterprise market nowdays. The corporate market if you will. Having used them since RH version 5, I can say that they've pulled a few stunts that have caused the traditional linux community some pain and aggravation. Systemd and Pulseaudio are the most notable examples aside from how they changed their kernel patch handling. I remember the days when they broke out all their kernel patches separately; you could download a tarball and pull out just the patches you wanted if you were going to customise your RH install. I finally said a sad goodbye to RH round about the time it became fedora. It simply became too much of a PITA to deal with. Sometimes I need a GUI desktop, (editing PDF's / Documentation) and GNOME didn't help matters any.

Re:From a security perspective...

[Guy Harris]

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

Shouldn't that read: "Disclaimer: verified using hacked OS image in an unsupported environment, your mileage may vary."?

No, it shouldn't, because it is a standard El Capitan running on VMware Fusion, not a Hackintoshed version of El Capitan running on some hypervisor to which Apple haven't given permission to run standard OS X.

(Sorry about the name mixup; I've been jokingly calling it "El Camino" for a while, but I meant "El Capitan", not "El Camino".)

Re:I assumed this was already a default

[sjames]

You mean other than forking off Devuan, for example?

Note that apparently nohup doesn't work when systemd is killing processes on logoff. That's because nohup follows POSIX standards but systemd doesn't.

Screen has worked just fine for many years, and still does unless someone screws up the system with systemd.

Re:I assumed this was already a default

[techno-vampire]

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?

Why don't you just use nohup, because that's exactly what it's designed for.

Re: I assumed this was already a default

[BronsCon]

But you've listed none of those insults such that he may grow and learn.

Since you knew it was wrong before you posted it, and speaking of growing and learning. Also, as an example the rpresser.

Re: Well fuck you, systemd

[Bing Tsher E]

Oh, I agree. I have hardware here that isn't worth turning on. More of it that I like to admit, but I'm a collector. I hate to see people with the attitude that it all should be shipped to the recycler, because there will be people like me in the future who enjoy old stuff. We don't need millions of Optiplexes mothballed everywhere, but there's a case for keeping some cool stuff around.

Re: I assumed this was already a default

[N!k0N]

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

Re: misleading title as usual

[Qzukk]

If you switch to a BSD then at least in 6 months you won't have to do it again when systemd adds +1 (fuck semantic versioning, every release is a Major Release!) to its version number and makes some other major behavioral change that you will have to audit all over again.

Re:From a security perspective...

[YukariHirai]

Personally I think this is a very good idea, and I know it's something I've considered on a few occasions.

The reason this is a problem is that when using home directory encryption you need a quick an easy way of making your data inaccessible, but as long as processes are running as your user the volume can't be unmounted, leaving your data open for everybody to read.

Killing all your processes and unmounting your encrypted home directory is a Good Thing(TM), and is semantically in-line with the meaning of 'Logging Out', aka - 'Im no longer using this computer'.

If you really want long-running processes it's pretty easy to create a separate services account, or use systemd containers, or docker etc.

Why so much fuss?

There must be other solutions to that particular problem that don't involve setting OS defaults that fuck everyone who has a use case different from "must at all costs keep encrypted home directory secure and inaccessible when not interactively using the computer". There are perfectly good reasons for having that as a priority, but it's not a priority for most.

Also, logging out does not mean "I am no longer using this computer", it means "I am no longer using this computer interactively". As many others have been pointing out, there are many reasons why a user would want processes to continue running while they're not logged in.

Re:From a security perspective...

[Peter H.S.]

You're an idiot. The name of the command is part of its functionality. If systemd were to insert itself in front of the bash interpreter and swap around 'rm -rf' and 'ls -lh', while preserving the 'functionlity' of one under the name of the other, who would need to be jerking you off under the table for you to claim that nothing has changed, and 'it's not a big deal, IMHO'?

Do you really think your made up, incoherent hyperbolic stories counts as technical arguments?

It is scary to think that you probably are old enough to shave yet behave like a retarded 10 year old. You mother must really have hated you since you ended up in such a sad state. I am sorry for you, I really am.

Re:Well fuck you, systemd

[WorBlux]

Well, yes, in fact I'm taking that option right now. However, I'm well aware I'm living on borrowed time. Console-it is dead and unmaintained, has been for a few years now. The only alternative for linux is logind. Going without one or the other really degrades the whole expected desktop experience. Given a server system, you should still be able to run for a long time still without systemd.

Re:From a security perspective...

[nyet]

As others have said, you're a fucking dumbass.

"nohup" exists everywhere. "systemd-run" does not.

Re:From a security perspective...

[nyet]

You can do that with a cron job, if you really want to be a completely dickheaded admin.

Re:I assumed this was already a default

[Curunir_wolf]

Even with the new settings, no user process will be killed on exit/logout if the user have told the systemd not to.

FTFY, jackass. systemd ain't my momma and never will be.

Re: misleading title as usual

[nyet]

Hey, dickhead: many of us run many many machines, and not all of them have systemd.

You can keep dismissing people who are smarter than you than calling what they're telling you "twaddle", but it doesn't make it so.

Re:I assumed this was already a default

[Truekaiser]

Um.. Alsa is the low level driver. Pulseaudio is the semi userland audio server that runs on top of it.
If you can't get alsa to work pulseaudio won't either. To be fair, pulse was only crap when pottering was controlling it. When it was dropped into the lap of others to maintain after he decided to do this whole systemD crap It got better.

Re:Sorry, Slackware is NOT an option. Nor is Gento

[Curunir_wolf]

I wish I had mod points, because I just squired milk out of my nose.

Re:From a security perspective...

[nyet]

Again, Peter, not all of my machines run systemd.

Re:From a security perspective...

[nyet]

Is there a single person here who doesn't think everything you post is complete shit?

Re:From a security perspective...

[RightwingNutjob]

Yes it does. It is an existence proof that refutes your claim.

What's scary is that you think that software "improvements" that end up making your users do *more* work to get the same functionality they had before are a good thing. Good engineering, you know things that customers are willing to pay for, has the property that it relieves the user of a tedious chore. A tractor that replaces two mules is a good example: who would pay for a tractor that took *two* mules to pull? Similarly, software that breaks compatibility for no good reason is dead weight that takes two mules to pull. Who the fuck would pay for that?

As expected - not a bug a mindset

[dbIII]

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

Re:As expected - not a bug a mindset

[thegarbz]

Or maybe these people implementing cgroups get the concept in a more clear and extensible way than you ever will. Now go and whinge to Debian for not picking a sane default configuration for their distribution. After all it is their job to make everything work. Lennart et al did his job just fine by making this behaviour configurable.

Re:As expected - not a bug a mindset

[dbIII]

No - massive breakage due to a major policy change that they just do not appear to be aware of. Definitely below the level of understanding of the average sysadmin. I've got no idea why you decided to get personal and attack me, but go ahead if you like and call me below average if that helps with anger issues since this is far worse than that.

It's a newbie mistake.

Background processes were in something like chapter 3 of an old introduction to bourne, ksh and csh book and early on in everything about *nix shells ever since.

Re:As expected - not a bug a mindset

[thegarbz]

Sorry for the attack on you. Not my intention. But calling out a lack of someone's understanding without understanding the reasoning does seem to indicate that they may know more about the topic than you are led to believe.

Not understanding is not something that can be claimed about systemd developers. Not only do they understand they are also trying to change to adapt to a different model. The switch to control groups as supported not just in systemd but through major Linux components since their creation 10 years ago necessitates the change, and the change is not that they are breaking the ability to use a multiuser OS, but rather changing the API.

Standard change practice:
1. Code new API.
2. Provide a compatible solution for everything that doesn't use the API.
3. Change the defaults to spur adoption of the API.
4. Life goes on.

We're currently at 3, and bitching about 2 while not understanding the basis for 1 which incidentally not only predates systemd, but dates back to when Lennart at al were busy playing with completely different projects and not even working on an init system.

Re:As expected - not a bug a mindset

[dbIII]

does seem to indicate that they may know more about the topic than you are led to believe.

You do not have to get down to the three digit slashdot IDs to find people who have been coding longer than Lennart.
These are newbie mistakes, not "moving in mysterious ways, but very obvious newbie mistakes. That they are still making them a decade into the project is a real worry.

Re:I assumed this was already a default

[mysidia]

Can we please get an architecture document from the Linux core developers LIMITING the scope of SystemD?

SystemD is supposed to be the Init / Service Management Daemon, and it should have no responsibilities related to managing user sessions.. That's Getty's Job, or SSHD's Job, for example, which is unrelated to what SystemD needs to be doing.

Re:From a security perspective...

[Anonymous Coward]

Don't confuse networking with what makes UNIX useful. See http://www.catb.org/esr/writin...

Sending passwords in the clear wasn't unique to UNIX, so it's a bit disingenuous to assert that.

Users doing things in insecure ways is a hallmark of Linux because users/developers started treating the system as a single-user box with annoying legacy multi-user cruft getting in the way.

Systemd is a natural result of treating the UNIX philosophy as a design flaw.

Re:From a security perspective...

[RightwingNutjob]

You edit my scripts. My scripts were working fine before. You made the change that fucked them up, it's on you to fix the damage. Where shall I send the bill to?

Incidentally, any place I would used ssh in a script with cached credentials or keys, I can probably use rsh with no security drawback. Because...you know...layered security and all that.

Re:From a security perspective...

[Curunir_wolf]

Just edit your scripts.

Are you serious? How about you edit my scripts? You broke it, you fix it.

Re:I assumed this was already a default

[dbIII]

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

[Taco Cowboy]

... Systemd is a pain ...

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

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

Re: Systemd is *more than* a pain

[hackwrench]

That sounds like Windows 10, only W10 will shut down silently programs that have open windows. Android can shut down visible processes ... Alright, between the lot of computer programs/OSs the terminology gets dodgy.

Re:I assumed this was already a default

[dbIII]

Different systems. You don't need alsa with pulseaudio and vice-versa, but most distros come with both since they both have weaknesses.

Re:From a security perspective...

[Curunir_wolf]

But please. WHY. THE. FUCK. break decades of well-established Unix conventions? Why the actual fuck? I hate the arrogance of the systemd folks who think they are doing everything better. Even Darwin respects Unix conventions more than systemd. And yes, they scrapped sysvinit too. And yes, I still prefer sysvinit.

Well established Unix conventions, like using unencrypted connections (Telnet, UUCP, rlogin etc) that sends password in clear text? Unix was chock full of insecure way of doing things and an unfortunately a lot of this have carried over to Linux with the end result that multi-user Linux security seems to rely on users being nice guys as a basic security measure.

With this change, people can at least ensure that their user run service doesn't DoS the server unintentionally.

No, it doesn't actually fix any of those possible issues at all. It does nothing to prevent them.

Re:From a security perspective...

[armanox]

It does create (which seems to be the whole idea of systemd) incompatibilities with other systems. Suddenly, I now have to care if my script is running on Systemd/Linux or if it is running on any other Unix system (and yes, I have scripts that currently work perfectly without modification on IRIX, Solaris, and Linux).

Re:I assumed this was already a default

[dbIII]

No problem - just change the way we do things to the way Lennart decided to do things this month?
Sounds like a problem to me.

Re:I assumed this was already a default

[dbIII]

What is a solid reason then which justifies breaking a lot of stuff and confusing users?
We think there are no solid reasons because we are not aware of any of them.
Instead of empty excuses how about some of those solid reasons? Are there any?

Re:From a security perspective...

[dbIII]

So please name me just one example of breakage or non-contrived stuff that are no longer possible to do with the new systemd settings?

Closed source workstation software. The user can't modify the process launch and put "systemd-run" in front of things and when they close the GUI launcher they still expect their stuff to run for hours or days instead of being killed off by a pointless major policy change.

RedHat should kill this with fire since it's a direct threat to the RHEL market.

Re:From a security perspective...

[dbIII]

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

Re:From a security perspective...

[Peter H.S.]

It does create (which seems to be the whole idea of systemd) incompatibilities with other systems. Suddenly, I now have to care if my script is running on Systemd/Linux or if it is running on any other Unix system (and yes, I have scripts that currently work perfectly without modification on IRIX, Solaris, and Linux).

Cross platform scripts have always been problematic. Sometimes they work, sometimes they get broken when things change. Solaris changed a lot with SMF etc, and Linux with systemd. That is just progress.

Most of the old close source Unix's have chosen not to evolve and are now firmly niche OS's working in a very narrow confinement (and loosing ground there too every year).
Linux runs everywhere, from tiny embedded to clusters and supercomputers, and therefore have other needs than classic Unix. It is just logical that Linux evolve with new features while many Unix's are standing still, and that therefore it will become harder and harder to run platform-independent scripts on them. While it may be inconvenient to some, it is what is saving Linux from ending up in the same, small dying niche as the close source Unix's.

In 10 years there will be even less Irix, AIX, Solaris etc., but Linux has a fighting chance still to be relevant in the future, exactly because it changes.

Re:Sorry but that's the normal behaviorostost

[Cassini2]

You don't want your long-running processes to have root privileges. It's a massive security hole. Many of the Linux daemons for server use run on less than root privileges (Apache, MySQL, etc).

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.

This is change overturns about 40 years of Linux/Unix computer history. The concept of nohup is used everywhere in Linux server land, and breaking that programming idiom will have significant ramifications.

Re:I assumed this was already a default

[ras]

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

[dbIII]

Well established Unix conventions, like using unencrypted connections (Telnet, UUCP, rlogin etc) that sends password in clear text

I'm truly convinced now - definitely trolling and having a laugh at all these geeky linux folk. Scum.

Re:From a security perspective...

[exomondo]

Perhaps you are unfamiliar with how open source works, they made a change in their project that suits them. If you don't like their change or contribution (or indeed their project) then you don't need to accept it, they don't work for you. These fundamental concepts of contribution start to get forgotten as a community moves from appreciative of contributions to a dependency and sense of entitlement. You either break your dependency on Red Hat or you accept that they are going to do things you don't like.

Re:Sorry but that's the normal behaviorostost

[hcs_$reboot]

Usually mysql and the like are started by root, but immediately do a setuid (mysql user). These processes will not be killed at log-off.

Re:I assumed this was already a default

[Ambient Sheep]

Have to agree with the person above me: the Backspace = Prev Page thing was a colossal pain in the arse... if for some reason you'd lost focus from a text entry box, you'd hit backspace and end up on the wrong page. There was no need to have Backspace do that; that's what Alt-Left (and Alt-Right for Next Page) are for.

Re:From a security perspective...

[Peter H.S.]

So please name me just one example of breakage or non-contrived stuff that are no longer possible to do with the new systemd settings?

Closed source workstation software. The user can't modify the process launch and put "systemd-run" in front of things and when they close the GUI launcher they still expect their stuff to run for hours or days instead of being killed off by a pointless major policy change.

Just lock the session instead of logging out. That would be the typical thing to do with a workstation since it runs a DE of some sort.

I must say I have a hard time imagine CLI software being launched from a GUI and then detach from the terminal. But I don't think there is any problem with using "systemd-run" on the GUI; that will create a new scope and anything executed from that scope will remain in it. So even if the GUI is closed, the scope will remain with all the processes launched from it.
At worst they can just add the user to the "KillExcludeUsers=" in logind.conf to have the old behavior.

Re:I assumed this was already a default

[Dog-Cow]

How about a statement from your doctor that you're fit to converse with other people? The "Linux core developers", whoever they are, aren't responsible for systemd, and have no say in its development. They can voice opinions, just like all the idiots here on Slashdot, but they have no vote or control.

Re:From a security perspective...

[dbIII]

Just lock the session instead of logging out

The pathetic little troll appears to have no idea that running applications remotely via X instead of MS Windows RDP is a thing.

Peter H.S. - why are you wasting all the time of all these people with your nonsense and deliberate antagonism?

Re:I assumed this was already a default

[Peter H.S.]

Even with the new settings, no user process will be killed on exit/logout if the user have told the systemd not to.

FTFY, jackass. systemd ain't my momma and never will be.

Maybe you need a real mother that can love you unconditionally for what you are. You certainly seem like a bitter bileful person in desperate need for love.

Re:From a security perspective...

[dbIII]

that will create a new scope and anything executed from that scope will remain in it

Something handed over to a thing like torque/openpbs or other scheduling systems will obviously not remain in the scope - as would many other things.
Closed source workstation software frequently has many parts and it is impractical to write little wrapper scripts around each portion that is called in a non-trivial way.

Re: From a security perspective...

[unrtst]

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: misleading title as usual

[Peter H.S.]

Hey, dickhead: many of us run many many machines, and not all of them have systemd.

Then use different procedures for different machines. Not a problem in the real world where people often work with several incompatible OS's. Anyway, that problem will solve itself as the non-systemd Linux machines slowly are phased out.

Re:Not a fan

[l3v1]

"killing leftover processes on logout. In my world, that's what I actually expect"

Well, he's simply an arrogant idiot. Usually, that wouldn't be a problem, but when it affects thousands of users, it surely becomes a big one. It takes a particularly huge moron to think everyone uses their computers like Mr. Know-it-all.

Re:From a security perspective...

[Peter H.S.]

Just lock the session instead of logging out

The pathetic little troll appears to have no idea that running applications remotely via X instead of MS Windows RDP is a thing.

X's network transparency have basically been broken for many years for anything complex. For simple uses of old legacy software it may still work for some. But really, I and many others are cheering for the day we can clean our systems for that insecure monster called X and start to use Wayland. Yeah, that will break peoples workflow too. But that is how progress works.

Peter H.S. - why are you wasting all the time of all these people with your nonsense and deliberate antagonism?

If you don't want me to answer your often rather unsavory personal attacks, then just stop talking to me. I don't remember starting to address you in the first place.

Re:I assumed this was already a default

[exomondo]

That's the shitty behavior you expect from Apple or Microsoft, not what you should get out of a system that runs on tiny embedded machines up to 1000+ CPU supercomputers.

You seem to be confusing Linux and systemd, when you say the "system" what is it you mean? Indeed Linux does run on many embedded systems, on many millions of smartphones and on most supercomputers but these do not run systemd and Linux is not systemd.

Re:From a security perspective...

[l3v1]

"Linux has a fighting chance still to be relevant in the future, exactly because it changes."

Well, you assume every change is for the better.

Which is idiotic.

This change is a perfect example.

Also a perfectly good reminder about the f*ing boundless arrogance systemd's developers are equipped with.

Re:From a security perspective...

[Peter H.S.]

that will create a new scope and anything executed from that scope will remain in it

Something handed over to a thing like torque/openpbs or other scheduling systems will obviously not remain in the scope - as would many other things.
Closed source workstation software frequently has many parts and it is impractical to write little wrapper scripts around each portion that is called in a non-trivial way.

It goes without saying, that if the close source vendors want to sell their stuff as supported on RHEL and E-Suse, and this is something they certainly will, they will make sure their stuff works with systemd.

Not familiar with "torque", but this doesn't seem like anything a single user will start from a terminal. It seems more like a fundamental system service, and therefore won't have any problems with "KillUserProcesses=yes".
Nor would any jobs it handed over to other machines be affected, unless it happens to "physically" login with username and password and run the instance under that user account. Highly unlikely IMHO.

Re:From a security perspective...

[Peter H.S.]

Well, you assume every change is for the better.
 

No I don't. I just accept technically superior solutions as the way forward, even if they means another way of working.

I have no sentimental feelings for old, close source, Unix systems made by money grabbing, Linux-hating companies. So I have no problems discarding ancient Unix ways of doing things if I find new ways that are better.

Finally, I actually study the new tech I embrace by reading the technical documentation. That is apparently a lost art among many modern Linux users.

Wiki says

[gnus_e]

"systemd is an init system used by some Linux distributions to bootstrap the user space and manage all processes subsequently, instead of the UNIX System V or Berkeley Software Distribution (BSD) init systems."

Re:Sorry, Slackware is NOT an option. Nor is Gento

[rastos1]

Slackware, on the other hand, requires far too much manual intervention just to get a minimally usable system set up.

I run Slackware since ... ever. At about 20 years. And using it as my primary desktop since ... ever. Browsing web, handling e-mail, watching movies, running LibreOffice, managing family photos, developing in C and Java, playing (admittedly older) games. Yes, occasionally I do some steps that I would not do on another distro - often because I want to, not because I need to. But the benefit is a system that is easy to understand, that does not screw up by itself. On the other hand I use some Ubuntu machines at work, and I'm baffled that some tools (nmap, whois, rpm2tgz, locate, ... ) are missing in default install. So I'm finding Slackware very usable.

Re:From a security perspective...

[nnull]

The syntax alone makes you want to kill them all. Stuff that used to make sense now makes absolutely no sense.

Re:Sorry but that's the normal behaviorostost

[mvdwege]

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.

Re:I assumed this was already a default

[mvdwege]

From that manpage: Also, please note that all limit settings are set per login. They are not global, nor are they permanent; existing only for the duration of the session.

Gosh, seems that limts.conf by design does not do what you say it does. If you log out, to what session does your screen process belong now? Systemd has taken the choice that unless you mark it as explicitly running in its own scope, it goes away with your session, something completely within the design spec of limits.conf. Yes, if you don't read the documentation, this comes as a surprise. True, the prinicple of least surprise says that defaulting to this behaviour is a bit less than optimal. But it is a reasoned deviation from the defaults, even if you disagree with it.

Re:Not a fan

[mvdwege]

Well, it's obvious who is the idiot here: the one who can't read and see that Martin Pitt explicitly mentioned that use case as not being covered by the new default.

Re:I assumed this was already a default

[Guy Harris]

Can we please get an architecture document from the Linux core developers LIMITING the scope of SystemD?

SystemD is supposed to be the Init / Service Management Daemon,

Can we, instead, get a project rename from the systemd developers, so that there's a name for the suite of programs they maintain that's not the same as the name of the process-1 daemon in that suite? That might keep people from making "that doesn't belong in the init daemon!" arguments about "systemd" when the "that" in question is being done by another daemon in the suite.

The offending behavior appears to be behavior of the systemd-logind daemon, which is the daemon that...

and it should have no responsibilities related to managing user sessions.

...is "a system service that manages user logins".

That's Getty's Job, or SSHD's Job, for example, which is unrelated to what SystemD needs to be doing.

Actually, getty, on many UN*Xes, is 1) run by the init daemon and 2) execs the login shell without forking, so that it doesn't stay around for the duration of the session, which means that the job of terminating the session when it's finished belongs to, err, umm, the init daemon.

Re:Makes sense ... but ...

[mvdwege]

If for worse, what's so bad at changing it? The worst I can think of is someone not reading the documentation on an upgrade and being surprised by the change, but if you upgrade critical system components without even reading the docs, let alone running them on a test system first, well, you deserve what you get.

Re:From a security perspective...

[Guy Harris]

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

[arglebargle_xiv]

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

Still no compelling systemd use case

[MrKaos]

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

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

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

Re:Still no compelling systemd use case

[GoingDown]

There is lots of things systemd does what sysvinit does not. For example:

* whole cgroups stuff
* Make service-private /tmp space
* Isolating services from network
* making directories read-only or inaccessible for service
* sevice monitoring
* dependency-based service startup

Re:Still no compelling systemd use case

[Entrope]

So you're saying systemd's functional delta could be easily replaced by a (at most) 500-line C wrapper that runs inside an init script?

Re:Still no compelling systemd use case

[thegarbz]

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.

Really? Because I can't remember the last time I ran a Linux system where init didn't launch some other daemon with the express purpose of handling all the stuff it wasn't able to regardless of how well you understood it. The concept of event based management of processes dates back to the days of 10MB HDDs and is something that init can't manage, never was able to manage, and is the reason that many projects and attempts have been made to replace it. The only difference is that this is the first one of the many attempts to be applied to more than one distribution.

As now I am being told that I'll have to make modifications to the way somethings that have worked for years.

For that you can blame the maintainers of your distribution. After all they are the ones who rolled out an update to you with a default blindly set from upstream despite it not being compatible with the way the rest of their system runs.

Do you systemd proponents actually have *any* experience on enterprise systems and how hard it is to get root access to modify these behaviors?

You don't. Just either a) make sure the defaults are set to suit your use case, b) use the provided workaround that systemd offers you as a user, or c) use software that supports the process model (admittedly this will be the hardest option since it's out of your control).

If you want systemd so badly - why don't you just make it a service of initd?

The irony of recommending the exact thing that systemd was made to avoid is unfortunately lost on the fact that this fundamentally doesn't work if any of systemd's functionality is to work at all.

Why are you guys, who cannot demonstrate you know any better, subjecting everyone to use this?

Who guys? The guys who invented cgroups? The guys who wrote kernel support for it? The guys who have put effort into replacing init over the years? The guys who compile a distribution with software of their choice to "best suit their users"? The guys who don't chose sane configuration options?
Who is subjecting you to use something against your will?

Re:Still no compelling systemd use case

[thegarbz]

Yes that's exactly what he was saying .... with the assumption that he doesn't know what the fuck he's talking about. For everyone else to do even some of the items of the list requires having access to the system before any software starts.

Re:Still no compelling systemd use case

[Etcetera]

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.

Really? Because I can't remember the last time I ran a Linux system where init didn't launch some other daemon with the express purpose of handling all the stuff it wasn't able to regardless of how well you understood it.

Woosh.

THAT'S EXACTLY THE POINT. Need something /sbin/init didn't already do? Have it launch another, specialized service manager of your choosing. Have it launch several! Original inetd, xinetd, crond, supervise/daemontools, linux-ha / heartbeat, ... plenty of options. Have it integrate with other systems however you need it to. That's why you're an administrator.

The point is: none of those other daemons pre-supposed that they were the only ones, pushed out other ways of launching services, or needed to exist as PID 1 (of which there can obviously be only one on a given running system). /sbin/init was kept simple and agnostic.

As now I am being told that I'll have to make modifications to the way somethings that have worked for years.

For that you can blame the maintainers of your distribution. After all they are the ones who rolled out an update to you with a default blindly set from upstream despite it not being compatible with the way the rest of their system runs.

There's blame to go around. The specific, stated goal of the systemd developers is to make it harder and harder to use configurations and setting that they do not approve of. Through a series of what they call "gentle pushes", they want to unify Linux userland across the distros. The history of the last 5 years is that the default will soon become mandatory.

But yes, fail on the Debain devs for not standing up for the distribution. (Fedora can't even do that any more... Fedora IS the upstream and there's basically no one who can push back at the Fedora level for a dumb upstream systemd decision. Debian... don't be Fedora.)

If you want systemd so badly - why don't you just make it a service of initd?

The irony of recommending the exact thing that systemd was made to avoid is unfortunately lost on the fact that this fundamentally doesn't work if any of systemd's functionality is to work at all.

Why are you guys, who cannot demonstrate you know any better, subjecting everyone to use this?

Who guys? The guys who invented cgroups? The guys who wrote kernel support for it? The guys who have put effort into replacing init over the years? The guys who compile a distribution with software of their choice to "best suit their users"? The guys who don't chose sane configuration options?
Who is subjecting you to use something against your will?

systemd was and is a power grab, plain and simple. Grab as much land as you can, make it "too convenient" to not give in to additional power requests on the grounds that it makes your own life easier, and suddenly the frog is quite boiled and you're trapped. Go back and look at any of the small decisions over time from Fedora 15 onward made to make it extremely inconvenient to use any other init system anywhere in the ecosystem. From hard dependencies to banning the inclusion of any sysvinit scripts (even as an option!) in RPMs in Fedora, which serves as the de-facto upstream for basically all RPM-based distributions. People who didn't want to use systemd absolutely were being subjected to it against our will. To claim otherwise is ludicrous.

The vast majority of systemd AS IT WAS ORIGINALLY PROPOSED does not need to function as PID1, because it forks other things from it. The only thing special about PID1 is that that's where parentless processes go. A systemd binary can launch other processes beneath it and remain in complete control over them for the vast majority o

Re:Still no compelling systemd use case

[MrKaos]

Yes that's exactly what he was saying .... with the assumption that he doesn't know what the fuck he's talking about.

or with the assumption you don't know what I am talking about. I really see no need for your zealotry, unless I assume you aren't grown up enough to have a polite conversation when you disagree with someone.

For everyone else to do even some of the items of the list requires having access to the system before any software starts.

Which is exactly what you need to do when you are designing and building systems that do different things as opposed to being a user of system or focused on the desktop.

Re:Still no compelling systemd use case

[JImbob0i0]

THAT'S EXACTLY THE POINT. Need something /sbin/init didn't already do? Have it launch another, specialized service manager of your choosing. Have it launch several! Original inetd, xinetd, crond, supervise/daemontools, linux-ha / heartbeat, ... plenty of options. Have it integrate with other systems however you need it to. That's why you're an administrator.

The problem is that this results in race conditions and "who watches the watchdog" type of scenarios. Plus if the intermediate supervisor dies for some reason the children with then be reparented to PID1, ie the basic simple init, and the restarted supervisor would then lose sight of them properly (ie no longer a parent so can't wait() on them).

Fedora can't even do that any more... Fedora IS the upstream and there's basically no one who can push back at the Fedora level for a dumb upstream systemd decision

Note quite. Fedora is not the upstream for systemd, systemd is its own upstream and frankly has been driven more by CoreOS needs than Fedora ones recently (with the whole resolved and networkd stuff which are not used in Fedora since we use NetworkManager). Check the number of patches in the F24 spec for instance. The discussion is ongoing at the moment and this will become a F25 change that gets debated by FESCO. It's likely that the Server and Workstation product, for instance, may split in their behaviours here given the different use cases.

systemd was and is a power grab, plain and simple

No it is an attempt to fix our broken init landscape (it's notable that no one wanted to keep sysvinit as the default in the Debian CTTE decision) and solved not only the sysvinit problems but the upstart ones as well.

Go back and look at any of the small decisions over time from Fedora 15 onward made to make it extremely inconvenient to use any other init system anywhere in the ecosystem.

Fedora is a well integrated distribution with a set scope of things supported clearly defined. Just as we don't support a BSD kernel the fundamental frameworks are made clear so that the stuff packaged can be well tested against that base.

People who didn't want to use systemd absolutely were being subjected to it against our will. To claim otherwise is ludicrous.

You are entirely free to use Slackware, Gentoo, Debian, Devuan or any other non-systemd distro you wish. It's notable that Arch and Suse switched to systemd of their own free will and neither are downstream of Fedora or subject to decisions there.

Re:Still no compelling systemd use case

[thegarbz]

THAT'S EXACTLY THE POINT. Need something /sbin/init didn't already do? Have it launch another, specialized service manager of your choosing. Have it launch several!

I didn't actually read the rest of your comment after this. If you don't understand why this is such a bad idea which every distribution either jumped at the opportunity to avoid, or better still several went out of their way to actively develop their own init systems because of it, then really there's no more discussion that I can have with you.

Continue to believe that you know better. ... Despite all the evidence.

Re:Still no compelling systemd use case

[MrKaos]

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.

The concept of event based management of processes dates back to the days of 10MB HDDs and is something that init can't manage, never was able to manage, and is the reason that many projects and attempts have been made to replace it.

I have already addressed this use case previously. There is no reason to force the rest of us into it, sufficient functionality can be derived from init for us all to be able to do what we need to do. You are blaming init for implementation issues.

As now I am being told that I'll have to make modifications to the way somethings that have worked for years.

For that you can blame the maintainers of your distribution. After all they are the ones who rolled out an update to you with a default blindly set from upstream despite it not being compatible with the way the rest of their system runs.

So this is an argument *for* systemd, blame someone else. Until this point I presumed that it's base functionality was static now you are telling me that not only does it turn existing knowledge into assumption its behaviour is inconsistent.

Basically you have just told me that systemd is worse than I thought it was as I've only been testing fedora. It is pretty clear to me that it is time to start reconsidering red hat's viability as a enterprise operating system. Thanks for the additional info.

Do you systemd proponents actually have *any* experience on enterprise systems and how hard it is to get root access to modify these behaviors?

You don't. Just either a) make sure the defaults are set to suit your use case, b) use the provided workaround that systemd offers you as a user, or c) use software that supports the process model (admittedly this will be the hardest option since it's out of your control).

Well, my experiences come from high performance computing environments so I'll share an alternate perspective.

I *want* init to be as simple as possible because I want to be able to isolate system behaviour. I do *not* want a monolithic process like systemd stealing context from my high performance processes. Lets say systemd generates a software interrupt or some other process on another core attached to it to generate logging I/O, wakes up its event manager, cron, networks or any other bit of functionality. In the scenario you describe not only do I have to do what you say, I'll also have to configure the cpu scheduler so it won't force minor page faults onto my process as it dumps my process from cpu cache to memory because systemd. You're saying that wading through systemctl and allocating CPUShares is a more logical choice than a lightweight process manager like init where I can leave that functionality disabled or simply isolate it it to a single core. As opposed to not quite having to care what initd is doing internally I *have* to know *everything* systemd is doing.

That's a lot of additional workload to make sure enterprise system behave as expected and it's apparent that systemd implements cgroups because it has to just to get back to what init did by design. I suspect there are going to be a lot of post incident reviews for those who don't account for this behaviour.

I've already considered the use case you cited and have performed a reverse analysis on the impact of systemd for my own use case so I'm pretty sure I know what the fuck I'm talking about.

If you want systemd so badly - why don't you just make it a service of initd?

The irony of recommending the exact thing that systemd was made to avoid is unfortunately lost on the fact that this

Re:Still no compelling systemd use case

[Etcetera]

THAT'S EXACTLY THE POINT. Need something /sbin/init didn't already do? Have it launch another, specialized service manager of your choosing. Have it launch several! Original inetd, xinetd, crond, supervise/daemontools, linux-ha / heartbeat, ... plenty of options. Have it integrate with other systems however you need it to. That's why you're an administrator.

The problem is that this results in race conditions and "who watches the watchdog" type of scenarios. Plus if the intermediate supervisor dies for some reason the children with then be reparented to PID1, ie the basic simple init, and the restarted supervisor would then lose sight of them properly (ie no longer a parent so can't wait() on them).

You're correct in that it can cause race conditions, but you're not giving sufficient weight to the fact that admins have heterogenous solutions for those. Who watches the watcher? Maybe a cron job. Maybe puppet. Maybe another service. Maybe monit or any other monitoring system you have. An administrator should look at their own likely failure states and automate accordingly.

How many times has xinetd crashed on you in the last 10 years? How often does daemontools or supervise crash on you? These types of servers are single-purpose designed and have well tested code. Small, simple, focused programs that do one thing and one thing well precisely to reduce the problems that can result. /sbin/init forking a shell and forking a small bit of C code (eg, svscan) with a monitor running via cron (and maybe a second monitor running persistently as a distinct service) is oodles more auditable, reliable, and understandable than a monoculture of systemd attempting to be responsible for everything.

Fedora can't even do that any more... Fedora IS the upstream and there's basically no one who can push back at the Fedora level for a dumb upstream systemd decision

Note quite. Fedora is not the upstream for systemd, systemd is its own upstream and frankly has been driven more by CoreOS needs than Fedora ones recently (with the whole resolved and networkd stuff which are not used in Fedora since we use NetworkManager). Check the number of patches in the F24 spec for instance. The discussion is ongoing at the moment and this will become a F25 change that gets debated by FESCO. It's likely that the Server and Workstation product, for instance, may split in their behaviours here given the different use cases.

Be fair. That entirely was the situation. It's a neat sophist trick, wearing the upstream hat and the downstream hat and claiming the other guy with the hat is tying your hands. (Not you personally, the collective "you".) https://bugzilla.redhat.com/show_bug.cgi?id=1170765#c58 The simple fact is that huge bits of what once had been Fedora-level policy is now more or less handled by "upstream" and there's continual pressure to not deviate from upstream. Anyone with any experience in any sort of team politics should be familiar with that.

systemd was and is a power grab, plain and simple

No it is an attempt to fix our broken init landscape (it's notable that no one wanted to keep sysvinit as the default in the Debian CTTE decision) and solved not only the sysvinit problems but the upstart ones as well.

Go back and look at any of the small decisions over time from Fedora 15 onward made to make it extremely inconvenient to use any other init system anywhere in the ecosystem.

Fedora is a well integrated distribution with

Re:I assumed this was already a default

[sjames]

How about the systemd kiddiez go get their own sandbox to play in?

Or at least quit proselytizing for a giant hairball that's hard to rip out.

systemd a trojan horse

[Anonymous Coward]

To me systemd is looking more-and-more like an industrial sponsored trojan horse (i won't be dragged into who sponsored it) to upend linux as the ramifications of this 'thing' is becoming increasingly ugly. It is truly a case of fixing something that wasn't broken.

Re:I assumed this was already a default

[Barsteward]

Probably quite a bit because no-one does any research on the issue before winding their neck out and making random ignorant statements especially as its just a configure change not a functional one.
From the fedora thread on this issue.. "systemd 230 now finally flipped the switch and finally by default cleans everything up correctly when the user logs out. But we do so in a very conservative way actually:
a) there's a compile time switch to turn this off globally (--without-kill-user-processes, not used in Fedora)
b) there's a runtime switch to turn this off locally on the system (in logind.conf)
c) there's a way to opt-out invidually for each user and each task from the cleanup logic, via systemd-run/loginctl linger. This operation goes through PK, and thus can be configured in a more strict or more open policy, depending on whhat the admin prefers.

Re:I assumed this was already a default

[Barsteward]

All they have changed is a default config option, just change it back or
a) there's a compile time switch to turn this off globally (--without-kill-user-processes, not used in Fedora)
b) there's a runtime switch to turn this off locally on the system (in logind.conf)
c) there's a way to opt-out invidually for each user and each task from the cleanup logic, via systemd-run/loginctl linger. This operation goes through PK, and thus can be configured in a more strict or more open policy, depending on whhat the admin prefers.

avoiding systemd in Debian

[ruir]

Please add to the /etc/apt/preferences.d directory a file with the following contents: Package: systemd Pin: origin "" Pin-Priority: -1

Re:I assumed this was already a default

[BlackPignouf]

Why don't you just use nohup [wikipedia.org], because that's exactly what it's designed for./blockquote
And that's exactly what systemd is breaking.

Re:From a security perspective...

[Barsteward]

The rant is more like: "Why is systemd on my system? It's overly complex, works poorly [for server systems], it breaks backwards compatibility, uses binary log files (WTF!), etc."

Blame your distro maintainers that decided to use systemd or choose another one that doesn't use one. Ranting from a point of ignorance is a waste of time and ignorance is the start point of all anti-systemd rants. The ranters would spend their time better if they RTFM on systemd and learnt how to configure it.

Re:I assumed this was already a default

[DrXym]

This hypothetical admin of yours should be competent enough to type "loginctl enable-linger someuser" if there is a reason they need long running services knocking around on the box. Or just disable the conf setting which was set to kill services in the first place.

I expect most admins would prefer the default behaviour to be to clear up left over processes and services when the user's last session disappears.

Re:Thats demonic

[shutdown -p now]

And ate my cat.

If it left the tail, you can probably get by.

Re:I assumed this was already a default

[MrKaos]

Why do you think there no solid reasons for this new default.

What are they? I haven't seen a compelling reason to replace systemd and I am wondering what they are supposed to be. I have test machines with systemd running and spent time getting my head around unit files and jounalctl and I see reasons why it is worse and none that it is better that the existing initd paradigm.

It is justifiable why a lot of people are angry about such a change being forced upon them. systemd is replacing a lot of core knowledge people have about the behaviour of their systems and turning that knowledge into assumptions. There is nothing wrong with learning something new if people understand that there is a good reason for doing so, however people with alot of experiences are being told to accept this change because.

Instead what we have seen is a demonstrated *mis*understanding of the way initd works with vague justifications by those pushing systemd. The only solid justification I've seen is because the rc.d initialization scripts don't work that well - and they were Red Hat's idea in the first place and they neglect to use inittab features of initd properly.

The burden of effort is not on those who have spent their time learning how to use initd properly to prove why systemd is a bad change, the burden of effort is on those who think systemd is a good change and why it is worth voiding my existing investment in time to learn how to use it.

Also, consider the precedent it sets. Somoeone spends their time learning systemd and a few years later the maintainers say "you know what systemd was a bad idea, we really need to go back to the drawing board and do it again" and we are back to where we started from.

You have assumed the mantle of suggesting this change is a good idea, so are you able to suggest a use case that systemd covers that initd does not? What specific things is it that systemd does better that can't be achieved with initd?

Re:Thats demonic

[arglebargle_xiv]

Well I've been watering it for a week but it's not growing another cat out of it.

Re:I assumed this was already a default

[sjames]

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

Re:I assumed this was already a default

[sjames]

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?

Re:Thats demonic

[shutdown -p now]

Man up already.

Re: misleading title as usual

[Barsteward]

Welcome to the world of system admin and maintenance......

Re:Thats demonic

[arglebargle_xiv]

Too late, I think I'm well and truly forked.

Re:misleading title as usual

[F.Ultra]

Is it really now insane to want ill behaved processes to be terminated when you log out of a session? I would say that this is instead expected behavior already by most users. That it _also_ happen to affect nohup and screen sessions are serious but I see no one that claims that this will be unresolved by the time v230 ends up in stable distributions. Once again this version is only available on Debian Testing, which is the correct place for you now, testing.

Good in theory, bad in practice

[Just Brew It!]

While "clean up after yourself" is generally a good idea (ask your mom!), in this case it is going to cause a lot of problems because it is being enforced from above in ways that will have unintended consequences because the enforcement mechanism doesn't understand context. I am sure that screen/tmux aren't the only tools affected.

Heck, I implicitly rely on persistence of background processes myself on a semi-regular basis. Doing something that runs counter to this expectation is going to break random stuff, and result in a lot of pissed off sysadmins. This behavior arguably makes sense for desktop distros, but given that Debian is primarily a server distro it should not be the default. Let downstream desktop distros like Ubuntu/Mint/etc. modify the default behavior, if they deem it appropriate (it doesn't even require a code change, it is a config option).

It is also symptomatic of the "all bow down before systemd" mentality, and I have a big problem with that. They may have good intentions, but there are some serious issues with how they're going about implementing their vision.

Re:Well fuck you, systemd

[F.Ultra]

yeah because it was that hard to understand that it was supposed to be "do not". What are you, a PowerShell parser?

Re: tmux and screen

[Barsteward]

apparently you know nothing about systemd's config

Re:Sorry, Slackware is NOT an option. Nor is Gento

[kjhambrick]

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

A.C. --

Please define primitive, very little effort and manual intervention.

I can have a fully functioning Slackware system up and running in 30 min, including formatting the HDD with very little manual intervention.

Slackware 14.2 is about to be released. It boots either BIOS or EFI and runs Linux 4.4.11 and a number of Desktop Environments, all without systemd.

There is now a set of 'slackware live' ISO images where I can run with persistence and optionally encrypted from a USB Drive:

http://docs.slackware.com/slackware:liveslak/

a complete 64bit Slackware-current Live Edition (in a 2.6 GB ISO);
a slimmed-down XFCE ISO (700 MB) with XDM as the graphical login manager. It fits on a CDROM medium or a 1 GB USB stick;
an ISO image (3.1 GB) of Slackware64-current containing Plasma 5 instead of KDE 4, with an addition of several other packages from the alienBOB repositories: vlc, libreoffice, calibre, qbittorrent, ffmpeg, chromium, openjdk, veracrypt.
a Mate variant (1.7 GB) where KDE 4 has been replaced by Mate (a Gnome 2 fork);
a Cinnamon flavour (a fork of the Gnome 3 Shell replacing Slackware's KDE 4).
a Custom variant which you can give your own name, its own package list and custom post-install configuration.

When I like what I see, there is an option to install liveslak to the HDD.

As I said Slackware 14.2 is about to be released. This version has succeeded in leaving systemd out while still being able to run the most recent releases of upstream Apps.

Have you actually looked at Slackware ?

There's a lot to like.

-- kjh

Re:I assumed this was already a default

[Barsteward]

unfortunately 99% of the troll or anti comments are from people who have not done any research or RTFM at all and make knee-jerk comments based on their ignorance and the ignorant comments of others.

Re: Well fuck you, systemd

[NotAPK]

"It's a fact that a super-cheapass PC these days can run a whole bunch of virtual machines each more powerful than a PC of not that long ago."

But now that nearly all modern CPUs have been infiltrated with side-band chips (see "vPro" and "SIMFIRE" etc...) it is extremely difficult to put together a trusted computing platform.

Those older systems, provided they are powerful enough to do the job, may have more value (for some tasks) than many realise.

Re:I assumed this was already a default

[Barsteward]

he's done his research before making accurate comments which more that i can say for 99% of the anti's. and i posit that the security of knowing what is legitimately running on my system after log out is reason enough.

Re:From a security perspective...

[Barsteward]

all the major distros seem to disagree with you.

Re:From a security perspective...

[Barsteward]

i thought it was very obvious, security of your system and the security of knowing what is still running legitimately after you logout.

Re:From a security perspective...

[Barsteward]

so its more work for you to write, test and maintain the script(s) etc to do this work when it could be configured once?

Re:From a security perspective...

[Barsteward]

good grief. if all your scripts of 10 to 20 years are without any modification in any way, that's future proofing in the extreme. (or no updates at all)

Re:From a security perspective...

[Barsteward]

now you are really grabbing at straws

Re:I assumed this was already a default

[Hognoxious]

Wouldn't have a problem with it being there, if it wasn't the only thing there.

Re: I assumed this was already a default

[fluffernutter]

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

Re:Well fuck you, systemd

[tiagosousa]

Console-it is dead and unmaintained, has been for a few years now.

There's a fork called ConsoleKit2 since last year which is maintained and, rejoice, there's no systemd in the minimum requirements list!

Re:From a security perspective...

[goose-incarnated]

Yes I am seriously suggesting to edit scripts so they work with new tech.

I would if this was new tech. This isn't new tech, it's old tech (MS-DOS/Win3.1) with a new name.

Re:misleading title as usual

[donaldm]

It however have to be said that just because v230 of systemd have changed "#KillUserProcesses=no" into "KillUserProcesses=yes" in /etc/systemd/logind.conf does not mean that distributions will ship with this. v230 have just hit Debian testing so it will be quite a while before it hits Debian stable.

In Fedora 23 with the latest updates the variable "#KillUserProcesses=no" is set in the /etc/systemd/logind.conf file. If this is not the case in Debian distributions then change it back to "no" -- hopefully, the problem is solved. Having an update change configuration settings is reprehensible and deserves the severest criticism. Well, I won't mention (cough!) a certain OS that a huge corporation is trying to foist on us --- for our own good of course. ;-)

Re:misleading title as usual

[donaldm]

Who's bitching about debian? No one.

Who's bitching about systemd's insanity? A lot of people.

Who's concentrating on things hopefully working in debian stable? You.

The problem appears to be Debian specific and not on other distributions.

The systemd process will only do what it is configured to do no more no less. If your configuration is changed as part of an update then the blame lies squarely with the update process for that particular package.

Look at the /etc/systemd/logind.conf file (check it's last modified date) and check that following is set "#KillUserProcesses=no". If it is set to "yes'" then set it to "no" and restart systemd -- problem solved.

One simple rule

[Damouze]

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

Re:One simple rule

[thegarbz]

Don't use X11 either.

Re:From a security perspective...

[silas_moeckel]

I question whether it's technically better or change to sell consulting hours etc etc.

What technical issue does this fix vs how much does it break. I've never gone OMG let me go clean up user processes left behind after logout it's taking my server down. I do not recall hearing others complain about the same. It's unix we have had the ability to spawn long running background processes forever and it's a known useful feature. Systemd is doing the old way is broken use the new way to get the same functionality. People seem to disagree with the old way being broken, I do. To me it makes far more sense to add something to logout maybe logout --killall or some such (mind you that may well allready exist) than have the init system killing processes. If I realy want my init system doing this I would want it restricted to a dumbusers group but a global on/off (I'm making assumptions here have not looked at the particulars for this "feature" as I have no need besides disabling it) seems far to heavy handed.

What this realy boils down to is them making a new way to do the old thing in an embrace and extend sort of way. How long till there is a global find/replace and the problem case is the same. Your problem user case will figure out the new way and your no better off.

Re: I assumed this was already a default

[Entrope]

The fact that they documented their broken choices, and incorrectly label them "very conservative", does not change the fact that the changes are stupid and break well-considered, long-standing behaviors in order to clean up after other software that is equally stupid and broken.

Re:Rapists

[jbolden]

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

[Entrope]

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.

Re:I assumed this was already a default

[jbolden]

That's standard behavior in OSX and iOS. Its easy to do once you start pushing through the idea that the OS's process manager decides what is going to be running.

Re:From a security perspective...

[silas_moeckel]

You do relize that those oh so bad programs are ancient? Back when you could not export any sort of crypto as it was considered a munition. Back when encryption was a massive amount of CPU time. We did have ways Kerberos existed, legally getting them out of the USA was very tricky.

If you're realy worried about lusers cgroups gives you far more protection than killing processes of a logged off user.

Re: I assumed this was already a default

[Barsteward]

eh? what on earth are you on about? are you replying to the wrong post? who said anything about malware being ok at any time? At least with this config change (if you keep it), if it is running it will be killed when you log out.

Gotta love computers these days

[houghi]

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.

Re:Gotta love computers these days

[strikethree]

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.

Amen. Wish I had mod points for you right now.

Re:I assumed this was already a default

[jbolden]

Process management is exactly what this article is about. There are no more serial terminals. The current state looks nothing like a bunch of physically wired terminals in a computer room and getty shouldn't exist. It should simply be replaced with something that fits the current paradigms.

As for sshd: sshd should be registering activities that need to survive outside a session with systemd. It has no way of knowing anything about global resources pools and can't make any intelligent decisions about how to handle scheduling. Its hard to think of a worse place.

Re: I assumed this was already a default

[Entrope]

You... might want to understand what you're criticizing before shooting off your mouth. Under POSIX, the login session lasts until the last process in it terminates, not until the login shell terminates.

Re:I assumed this was already a default

[jbolden]

This is standard on OSX and has been part of Unix for many years.

If there is a just a slow FTP then everything is fine. Slow is not the same as off. If it goes off, then the daemon (if configured) wakes periodically and checks if it can resume. The system process monitor decides though when the right time to run these "it can wait' daemons.

As for distros that is what's happening. There are systemd distros and non systemd distros and they are forking further and further apart.

Re:I assumed this was already a default

[Barsteward]

yawn... Pen and paper used be the way to do things so whats your point? if you don;t like tightening up security on your systems, thats up to you. I presume most of the anti are like the manual workers of old who were worried that computers would take away their jobs and in this instance systemd is taking away manual tasks from you.

Re:I assumed this was already a default

[jbolden]

And tell your system you want that. You can change default config on Unix.

Re:I assumed this was already a default

[Barsteward]

glad to see you love nostalgia

Re:I assumed this was already a default

[jbolden]

How many "multi user" systems are left anymore anyway?

Many billions. There are now many dozenss of exabyte datacenters. Those aren't filled with single user machines. AT&T sells over 1/2 their cellular bandwidth to embedded systems.

The single user computer is still important but it is not the norm.

Re: I assumed this was already a default

[Entrope]

/. must have associated my comment with the wrong one of your spammy comments. I was responding to your assertion that now only "legitimate" processes will be running when you log out. Clearly, you don't have a clue about why that is *not* a pro-security approach.

Re:I assumed this was already a default

[jbolden]

How does an admin allow you as a user to run arbitrary code that consumes arbitrary resources and protect everyone else? He can have an operations staff or maybe a scheduler but that's precisely what systemd is laying the groundwork for and making possible on Linux.

The problem systemd fixes

[ACE209]

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

Re:I assumed this was already a default

[jbolden]

The point of systemd is process management. To give to Linux what Solaris, Digital Unix, AIX... have for big box. To give Linux what mainframes have (or at least some fraction of it) since Linux is replacing those use cases. And on the desktop to give Linux what Windows and OSX have.

Not best practice

[DrYak]

How about doing anything that takes a long time and you don't want to remain logged in for it to complete?

You use screen for that. (My phone, SailfishOS powered Jolla, has this kind of session clean-up enabled on its systemd. Screen is *the* way to do long-duration running).

Or nohup (though I'm not sure if that one is considered as a separate login-session)

so you redirect stdin to /dev/null, stdout to one file, stderr to either the same file or another file,

If you just muck around with redirections and process in background, chances are it won't be correctly dettached/disown.

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.

It's 2016. We're at the Internet Age.
You don't need root privileges to wreck havok on the network.
And End-User's privilege level is far enough.

Same to do shit on a user's home directory:
A ransom ware doesn't need root privileges to encrypt all end-users' data neither.

e.g.: a Firefox browser of which you've closed the main windows, thus quitted the GUI. But for some reasons there's still a process running in the background.
(It does happen from time to time, when its clean-up procedure is stuck in some loop).

Such a process, which is clearly *not a daemon* would still linger around under older rules, and if that daemon has network access still open and could be hacked, then damage could be done. The setting in logind.conf is one way to handle this kind of scenario (and apparently the debian packagers have decided to turn this on).

But normally, there are clear rules that one must follow to create a daemon:
- old style, pre-systemd: double-fork so the grand-child process gets assigned to PID1, along the necessary file descriptor handling.
- systemd-style: normal process, but launched using a .service conf file that defines it as a daemon.

For anything else, you should use at best screen.

Re:Not best practice

[Junta]

One, no one has credibly stated that screen/tmux are left alive. There are people reporting that screen/tmux sessions are killed.

For another, do the firefox sessions that you describe survive a logout today? In order to survive a logout (exit of gnome-session or whatever), the process has to setsid to establish itself as a session leader, I have seen firefox misbehave and run with no GUI active, but I've never seen it survive a logout given current scenarios.

Re:I assumed this was already a default

[jbolden]

This is Linux. Software competes. Upstream gets to decide what mainstream distributions do. At this point the alternative approaches get a sandbox and they have to convince people they have a viable approach. (excluding on embedded where non-systemd distributions are doing fine for now).

Re:I assumed this was already a default

[jbolden]

POSIX is decades old. POSIX was designed to solve the problem of competing big box unix solutions and the difficulty of writing software for all of them. We don't have that problem anymore Linux bankrupted most of them and the rest are being shutdown slowly. big box Unix is dead and Linux now has to deal with their customers.

It is still difficult to write software for the various Linux distributions but POSIX doesn't help that. LSB is likely the new POSIX. And LSB is actively supporting systemd as an option.

Re:I assumed this was already a default

[jbolden]

Everyone would have been happier if one of the other solutions had panned out. The Linux community isn't used to someone just winning. They are much more used to choice. But openrc and upstart both failed. Someone won, and now we have a new standard.

There are many distributions that don't use systemd but they are more niche. Try something like puppy if you hate systemd.

Re:I assumed this was already a default

[jbolden]

Dude it is time for you to accept init lost. The principle of least astonishment is following systemd policies. The reason you are being astonished is because you are expecting things to work like they did in the days of init.

Re:I assumed this was already a default

[jbolden]

Of course there is good reason. Only the process manager has the global knowledge of the competing demands to make intelligent choices about resource allocation. Given competing demands for a system to work well intelligent choices need to be made about what should be running when. That's systemd's job.

Re: I assumed this was already a default

[mvdwege]

It's really a bit more complicated than that; a session lasts until the session leader kills all other processe; but even so, just because something's always been done that way does not make it a bad idea to try and improve upon it. And yes, I consider the systemd solution of using cgroups to create another sessions scope an improvement.

Re:I assumed this was already a default

[jbolden]

Runtime dependencies:
Process A depends on B which depends on C which depends on D which depends on E.
C crashes. You restart C. What do you do with A, B, D and E?

Re:I assumed this was already a default

[goarilla]

And if they wanna watch star wars, they telnet to towel.blinkenlights.nl
or mplayer -vo caca|aa videofile.

Re:From a security perspective...

[mikelieman]

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

Hey, if i understand the way logind works, if you login as root and run the process under screen, it won't kill the process when you logout!

An easy work-around that doesn't require configuration file changes!

Sure *some people* will complain that it's a risk, but hey, it gets you moving forward again and you can close that ticket.

Re: I assumed this was already a default

[Entrope]

"It ain't what you don't know that gets you into trouble. It's what you know for sure that just ain't so."

No, it is not more complicated than what I said. A typical session leader does not kill the other processes in its session (or even process group). At some point -- say, because the login shell (which was the process group/session leader) exited -- the kernel sends SIGHUP to all the processes in the session, and the default handler for this terminates the processes in the session, and thus the session.

How is using cgroups an improvement over the POSIX way of doing things?

Re: I assumed this was already a default

[mvdwege]

Yes it is. It is up to the session leader to handle the session. If you're going literal on me, I'd ask you nicely to point out where in the standard it says otherwise.

And cgroups are an improvement because they finally have one overarching system to classify processes, with a unified interface, and resource control for the entire group. Isn't that self-evident?

Re:From a security perspective...

[drinkypoo]

good grief. if all your scripts of 10 to 20 years are without any modification in any way, that's future proofing in the extreme. (or no updates at all)

Yes. UNIX: FUTURE PROOFING IN THE EXTREME. That should be the fucking slogan. Only total fucking newbies don't think that's a dramatically compelling feature.

Re: Well fuck you, systemd

[drinkypoo]

But now that nearly all modern CPUs have been infiltrated with side-band chips (see "vPro" and "SIMFIRE" etc...) it is extremely difficult to put together a trusted computing platform.

So what? I don't use computers in my secret plans to rule the world. I keep that stuff offline, in a safe protected by pyrotechnics. Or at least, that's what I would do, if I were a fucking supervillain. The rest of us don't need to worry about spy chips. What we need to worry about is creeping fascism. It's been possible to spy on computers forever. What is needed is to root out corruption, and keep rooting it out, because weeds take root whether you want them to or not. And the seed will always be there so long as people have unmet needs, physical or psychological.

Re: I assumed this was already a default

[Entrope]

The standard says "If the process is a controlling process, the SIGHUP signal shall be sent to each process in the foreground process group of the controlling terminal belonging to the calling process." No action required by that controlling process, or even discretion about it.

No, it is *not* self-evident that cgroups are an improvement for login sessions. For virtualization, sure, they make sense -- but I am unconvinced that the same kind of resource quotas make sense for login sessions.

Re: I assumed this was already a default

[mvdwege]

Then we will have to disagree, because I like being finally able to hedge off a part of my processes and manage their resources in ways that login sessions and process leaders don't provide.

Re: I assumed this was already a default

[Entrope]

I can understand wanting to apply resource quotas to some subset of processes. What I don't understand is tying that to a user's interactive session, much less using additional mechanisms to reproduce sessions/process groups, as systemd is doing in this case. It seems to me that you're defending using cgroups, which is only coincidentally related to systemd's behavior.

Re:From a security perspective...

[Junta]

The thing is that there are already facilities to do this in *nix land that have existed for a very long time (why else do things like nohup exist). This new tech means now processes have to do *yet another thing*. Imagine 10 years down the line with processes abusing systemd-run, and someone deciding to standardize a new behavior that requires wrapping systemd-run, since it was so abused. That's the absurdity, software is abusing the facilities available today, so they put in another block that invites software to abuse more facilities to overcome that, rather than pushing back on the software to *STOP ABUSING FEATURES TO KEEP RUNNING THAT SHOULDN'T*

Re:From a security perspective...

[Junta]

The problem being that after years of struggling with unsupported OSes, RedHat managed to represent a hardware vendor friendly option that did pretty much what we wanted. Fork and move on is not something the hardware vendors (and by extension, large IT organizations) will go along with you on. This is beyond open source. RedHat managed to sway Debian and by extension Ubuntu didn't have the will nor even did SuSE. So there are zero supportable new Linux distros that provide the non-systemd experience. This is a big problem in and of itself, but also an indicator that there really isn't meaningful choice in distributions as they all just copy RedHat's moves now (even though Ubuntu, by install count far outnumbers them, RedHat still has the muscle by virtue of revenue).

So RedHat now starts moving on to chase markets currently out of reach for them, with an effectively captive audience of their original market, telling them to shut the hell up and deal with it. It's a lot like Windows 8 throwing their traditional desktop users under the bus for the sake of trying to get them into the tablet/phone game. Just like windows 8, I see a *lot* more customers running RHEL6 than I saw running RHEL5 this far into the next-gen's life. I've also had to work around all sorts of breakage with systemd (there was an upgrade process that did a yum update as a service. One day a systemd update landed, and the upgrade process got killed when it tried to update systemd because old-systemd would kill off the update procedure in the process of the systemd update being applied).

Re:Sorry but that's the normal behaviorostost

[Entrope]

If non-buggy software is running in its own process group, that's a pretty darn good indication to a competent sysadmin that it is meant to hang around.

That GNOME software is buggy should be news to nobody.

Re: tmux and screen

[Entrope]

Apparently you know nothing about the principle of least surprise.

What is more obvious, more common, and more widely understood: "nohup foo &" or "systemd --magic-grok --yes-i-want-this-to-stick-around --user --of-course-i-mean-user foo"? Which one has been the standard way to keep things running after a login shell exits for about 40 years?

Re: I assumed this was already a default

[mvdwege]

Erm, no, I'm coming at this from the other way: because I now have a way to apply resource quotas to a group of processes, including putting them in their own scope that's no longer dependent on an interactive session, I don't mind that ending an interactive session kills all processes except those specifically exempted.

Re: Rapists

[Dr_Barnowl]

You never log out of your cellphone. You either lock the screen, or shut it down.

Re: I assumed this was already a default

[Entrope]

Why is it okay to break the 40+-year-old method for preserving a process after the login shell exits just because there is an orthogonal mechanism for applying resource quotas?

Re:From a security perspective...

[dbIII]

X's network transparency have basically been broken for many years for anything complex

If you mean the current gnome that was deliberate on the part of the gtk+ developers since they decided it was not important and to rely on hardware acceleration instead of writing something that would work properly without hardware acceleration. If you mean otherwise you are lying.

If you don't want me to answer your often rather unsavory personal attacks

Pointing out your attempts to pick fights is addressing your actions and is not a personal attack.

They always break the build.

[MouseTheLuckyDog]

The systemD teams reminds me of "the team".

You know the one that keeps submitting those changes Friday at the end of the day, so that everyone coming Monday discovers that the build has been broken. So you spend the next two days chasing around things that they broke. Meanwhile the managers are wondering why the project is falling so far behind.

I think in the long run Linus is going to take it over and do something similar to git.

Re: Well fuck you, systemd

[NotAPK]

So you're saying that change through political means will result in a better outcome than technical ones?

Good luck with the upcoming election, I've got a hunch Trump's gonna win :)

I know you're being facetious regarding "secret plans to rule the world" and it made me chuckle, but let's bring it back down to earth with a more realistic example:

Here in the UK the home secretary is trying to pass legislation that would give the local police unrestricted access to all home internet access records kept by the ISPs. I can see the logic as to why they want this power, but in my opinion it is too much power for the national intelligence agencies, let alone the local police. It's mind boggling to think that a Cold War (risking MAD of all things) was fought over the right to "privacy" and "freedom" (or at least that's what came out of the propaganda machine in the West) and there was much ado about protecting the privacy of library book loan records at the time, which is in my opinion the simplest comparison to the privacy of online internet records.

So, anyway, while I have written letters to Ms May and my local MP, and I have voted in all of my elections, there is actually nothing else more that I can do. ...except implement technical means to circumvent the snooping: just using a very simple VPN to another country allows me to "shift jurisdiction" as to who has my internet browsing records, and the worst case is that it is now a different police force than the one that can barge into my home at 5am with their weapons drawn.

Of course I'm now technically breaking the law, but in my case I think my actions are just. But even that's not really appropriate for the end game, and I fear that after pushing on for some time trying to change the system through peaceful lawful means, my only other option will be to leave and find somewhere else to live. There is no way a rebellion here in the UK could succeed, and I've read too much to know that even uttering any desire to start one is a very bad idea. The whole situation sucks.

Re:I assumed this was already a default

[sjames]

I have many linux systems. No systemd in sight. Never will be.

Consider it my vote of no confidence.

It's clear you have no idea how the principle of least astonishment works.

Re:Sorry but that's the normal behaviorostost

[drinkypoo]

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.

If systemd needs a special tool to know that a process which has been detached from its parent is meant to hang around, it's not very smart.

If Poettering can't make pulseaudio terminate on logout like a process should, maybe he should fix that.

Re:From a security perspective...

[dbIII]

they will make sure their stuff works with systemd

No they will do what they have always done and specify an older platform that works.

Not familiar with

From your comments you do not appear to be very familiar with the *nix platform at all - your terminology of "service" seems to indicate a MS background so I suppose that makes sense. Please learn some of the subject matter before delivering such a stream of "corrections" and ignorant lectures in the future.
The X lie was especially hilarious as if all you know about X is from reading what Wayland fanboys who have never run either X or Wayland have spouted in ignorance.

Re:I assumed this was already a default

[sjames]

How will you keep TCP connections from timing out?

Re: I assumed this was already a default

[drinkypoo]

cgroups are an improvement because they finally have one overarching system to classify processes, with a unified interface, and resource control for the entire group. Isn't that self-evident?

cgroups are good, but they are not a systemd feature, they are a kernel feature. They are manipulated with short, simple commands (creating and destroying them is done by manipulating files and directories) and there was no need for a whole new daemon to implement them. They could have been implemented easily enough in the init scripts.

Re:I assumed this was already a default

[sjames]

You may be a bit confused. What daemon? I'm talking about good old ftp on the command line. I connect and start a download that I expect to take 12 hours or so (huge file or slow server, doesn't matter why). How is the system going to save state such that when restored it's still connected and downloading?

For a service, there is no periodic wakeup. It just needs to block on accept. When a connection comes in, the accept call returns.

Re:I assumed this was already a default

[sjames]

That doesn't even begin to make sense. There is nothing more or less manual about systemd and it's not going to do anything for security (but potentially introduce new holes).

*slow clap*

[OrangeTide]

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

Re:I assumed this was already a default

[sjames]

I just prefer well designed systems. Init may not be the best, but systemd is a step backwards.

Re:I assumed this was already a default

[sjames]

Linux long ago replaced all of those in most applications. I have yet to hear of anything systemd can do that wasn't already being done.

Re: I assumed this was already a default

[mvdwege]

Because the alternative mechanism is better, IMO.

Re: I assumed this was already a default

[Entrope]

The "alternative" mechanism you describe just isn't an alternative, it is orthogonal to the behavior under question. Again: Why is it okay to break the thing that has worked essentially as long as UNIX has existed just because an independent mechanism (for doing something entirely different) exists?

Re:I assumed this was already a default

[sjames]

Funny, I've not seen this difficulty in development. All systemd "contributes" is yet another variation that has to be accounted for.

For example, the subject of TFA. Until systemd came along, there were a couple good ways to not get terminated on logout. They worked across *BSD, Solaris, Aix, Unicos, and the many flavors of Linux (perhaps Mac as well). Now, not so much.

Re:I assumed this was already a default

[jbolden]

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

[jbolden]

You have heard. Process management.

Re:I assumed this was already a default

[jbolden]

Correct. systemd is part of a broader system that is replacing POSIX. No one is arguing that POSIX never existed. Nor is anyone arguing that systems that don't adopt won't be left behind. As for Solaris and AIX they both had process managers. Not getting terminated on logout was up to the process manager not the end user.

Re: Rapists

[jbolden]

You likely don't log out of your cell phone.

As for stopping process that what iOS does for most to conserve energy. Only those systems entitled to run in the background are allowed to run anything and even there the system makes the choice not the application.

Systemd

[Tenebrousedge]

RedHat managed to sway Debian and by extension Ubuntu didn't have the will nor even did SuSE.

Horseshit. Stop acting like this is some big conspiracy. The pages of pro and con discussion are still on the Debian wiki. Systemd was selected because it was technically better than upstart, not an unholy maintenance nightmare like SysV, and had more features than OpenRC.

Systemd and cgroups are fixing things that have been broken since the 70s. Usably broken, I grant you, and well-known, but still fundamentally flawed. We have some forty years worth of technical debt accumulated on top of these systems, and frankly I'm surprised that they haven't broken more things. We should not pretend that there are not logical reasons for the changes nor that they are not subject to public scrutiny and input. It definitely looks like a big problem though, if you ignore those factors.

Re:Systemd

[Junta]

The problem with systemd is that there are so many different fronts to argue on, that either side can pivot around and misconstrue the other viewpoint. Here for example we are talking about user session management. SysV init had nothing to do with that. Another common complaint is logging. Again, sysv init had nothing to do with that. A few folks complain generally about systemd's approach to init, but overwhelmingly the gripe is about crap like this and binary logging. So when folks rightfully object to some sort of intrusiveness with respect to user session management or asinine binary logging, proponents fire back with 'but sysv init sucks!' which has no bearing whatsoever on the discussion at hand.

When it comes to init and perhaps even atd and crond, I'm personally not too terribly bothered by systemd's approach. The binary logging is complete and utter horseshit, the larger activity of boot still has a whole lot of bugs that are very difficult for admins to debug, but that's not a condemnation of the systemd approach, but a complaint about the relative maturity of the implementation. This whole article is so far removed from what *init* should be doing, that such a counter-argument about sysv is ridiculous.

Re:I assumed this was already a default

[Hognoxious]

Ah. Those were the only choices, were they?

Re:I assumed this was already a default

[sjames]

So name one.

Re:I assumed this was already a default

[sjames]

Go back up and figure out what we're talking about. The sub-topic here is saving state.

Re:From a security perspective...

[RightwingNutjob]

What the fuck do you actually do for a living? The way you're talking about this stuff, I'm starting to suspect you push a broom for a living and computers are just a hobby.

Re:I assumed this was already a default

[sjames]

You're going to have to be more specific because I have process management now without systemd.

Re:I assumed this was already a default

[jbolden]

Pretty much yes they were. In theory there might have been hundreds of choices. In practice there were just a handful.

Re:I assumed this was already a default

[jbolden]

Same example I've given you. A depends on B depends on C depends on D depends on E. C crashes and the system is able to recover. What does the operating system do with A, B, D and E to get them aligned with the new state?

Re:I assumed this was already a default

[tburkhol]

I expect most admins would prefer the default behaviour to be to clear up left over processes and services when the user's last session disappears.

This is the problem. You, and the systemd maintainers, know your use case and 'expect most admins' to have the same set of problems and expectations. I imagine the change in default will be very handy for people who maintain computer labs, where the computer is only expected to be doing something if someone is physically present at the console. Very handy if your computers are only used to deliver content to users.

Maybe that's even a majority, now that we've reduced "computers" to fancy televisions. To people who've been around longer and actually use the computational power of the system, this change will break a lot of existing scripts and functionality. Those people are going to be inconvenienced because people who maintain interactive-only systems can't be bothered to disable persistent processes on their own, or to type "loginctl disable-linger someuser" for people they don't trust with unattended processes.

Re:I assumed this was already a default

[sjames]

Incorrect. Solaris worked much like non-systemd Linux works. Dettach from the controlling tty if you want to keep running. Either in the program itself or use screen or nohup to do it for you.

All systemd is doing is adding an incompatible behavior.

I am systemd ...

[Rambo Tribble]

... and all your process are belong to me.

You can disable it.

[Eravnrekaree]

I always thought child processes were killed when the parent was killed, anyway, unless it was deamonized with nohup. I dont know whats new here. The behaviour can be disabled, so if you dont like it, just disable it? Whats the big deal.

Re:You can disable it.

[jon3k]

I always thought child processes were killed when the parent was killed, anyway, unless it was deamonized with nohup. I dont know whats new here

Child process ARE killed by default when you logout, unless you explicitly ask the system to keep them running (ie screen/tmux, nohup, disown, etc). Now when you logout, by default, it will kill even the processes you asked the system to continue running. Why would the default behavior be to ignore my instructions to keep processes running?

The behaviour can be disabled, so if you dont like it, just disable it? Whats the big deal.

The problem is this changes long running default behavior for no reason.

Re: misleading title as usual

[Kickasso]

Then use different procedures for different machines

Bravo. All these people calling you a fucking moron can shut the fuck up now. You are quite capable of proving it yourself with one short sentence.

Re:I assumed this was already a default

[sjames]

Since it would have been easier to name one, I conclude you have no idea.

systemd is far more decentralized and modular

[Eravnrekaree]

Can anyone say zombie process? Its long been the case that if you kill a parent process, children get killed to. Unless, you demonize it with nohup. You can also disable the behaviour in systemd.

systemd is overall a good concept, and is not some monolith. Its a good idea to have the init system be a IPC standard using DBUS, the kernel creates system event messages on dbus, you can have an init daemon listen for these messages and have whatever logic you want in there, if you want to start a process when the network card goes up, you watch the dbus for a network card up message from the kernel, when recieving this you will start your process. When a process is started, that can be announced on dbus as well. The possibilies, modularity and decentralization and configurability of this model far exceeds that of the old system. Highly modularized and decentralized, even more so than the older init model. The old system V init is still supported, so if you dont like the new style, you can always set your services to start with a traditional sysV init script. So whats the problem?

Re:systemd is far more decentralized and modular

[Entrope]

The problem is that systemd's new default is to also kill things that were started with nohup.

Re:I assumed this was already a default

[sjames]

Can you name a case where that condition is more than theoretical? Preferably one where the correct answer isn't one script starts them all in order?

The closest thing I have seen of that nature is something depending on the database. If it gets a connection error on a query, it tries to reconnect. If it can't, it serves an error message.

Re:I assumed this was already a default

[jbolden]

Sure tons of enterprise apps. For example you have an app (A) tied to a database (B) tied to a virtual slave (C) copying information to kafka (D) which is being picked up by Hadoop process (E1) which then does batch transformation (F1) which then at the same time D is picked up by Spark (E2) which creates RDDs (F2) which then creates windows (G2) both F1 and G2 feed Elastic (H).

C crashes who needs to be notified and how?

Re:I assumed this was already a default

[jbolden]

I understand what saving state is. Reread the answer.

Re:I assumed this was already a default

[segedunum]

A multi-user system shouldn't allow unpriviledged users from consuming resources indefinitely. It's too easy to starve a system or resources.

Errr, setting appropriate user resources is the way to do this, and there are various methods to do that. Killing everything isn't, and there are any number of things you'd want to leave running so that when you log back in you log back in to the same state. This is the kind of moronic nonsense you get when developers override system administration practices that have been around a very long time for a reason.

Re:I assumed this was already a default

[segedunum]

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

[mvdwege]

Eh. Wrong checkbox. That post was mine, if it wasn't obvious.

Re:I assumed this was already a default

[jon3k]

How does this have anything do with management of allocation of resources to users? Isn't an interactive session just as capable of "consuming resources indefinitely" as a running detached process?

Of course. We have this fancy little thing called cgroups and limits.conf. Any argument that the system is somehow "safer" or "more secure" because a process can't keep running after logout is so ignorant that you have to immediately realize it's not possibly the real reason for this change. This is a change because of the incestuous nature of systemd and GNOME.

Re:I assumed this was already a default

[Midnight Thunder]

In a shared desktop environment you often only want the process of the currently logged-user and authorised daemon tasks. Anything else is consuming CPU cycles that are perceived as getting in the way of the person using the system.

As to resources being saved: CPU, memory & power. There are an increasing number of offices that will put their machines to sleep at night, once idle after a certain period. If you needed you process to be working outside of your session, then you probably want to be running this on a server or stay logged in.

What "ALREADY FUCKING WORKS"? Applications already receive notifications to save their state when the user is being logged out or "Windows style" simply loses anything that was active without notification?

Re:I assumed this was already a default

[DrXym]

I'm sure the Debian package could have handled things better such as warning the user or asking them for the behaviour to adopt. But I'm sure it's not the first time a package has locked itself down or changed a default in a way that improves stability / security / performance or whatever and has required some workaround to deal with. I don't see people running long standing tasks after they log out of a PC as being a major use case and therefore it makes sense is the default doesn't allow it to happen.

Calm down, easy fix

[ebvwfbw]

There's a program called screen. It's been around for decades. Used to be we'd lose out connection on our dialups, then firewalls used to get us due to inactivity. Someone wrote an ingenious program called screen. It'll survive those things. Just run whatever you want in that window. You can then detach and later reattach. No problem. The bummer is some of the key bindings conflict with Emacs.

BTW, this isn't a "system D" problem. It's a change to how the shell works. It's been there for years. Stop being systemd haters, get over it already. Man up and learn it. I did and I have over 30 years of working with the old SYS V and BSD. If you don't want to learn it because it's too hard (as if it's too hard), do something else. There's plumbing, electrical, house framing, welding. All of those fields need a lot of people. You'll have to learn stuff there as well, however. Some places require the old Union progression. Journeyman, Master, etc.

Re:I assumed this was already a default

[segedunum]

What the ... ?? Is this a troll? You can't be serious. C'mon - what the hell is this shit?

Yes it is a troll, and the same usual suspects crawl out of the woodwork on here every time when systemd fucks something else up. Anyone who has done system administration for any length of time knows that sessions != individual users for very good reasons and anyone who tries to equate the two hasn't the faintest idea what he's talking about. We'll eventually regress to single user systems.

Re:I assumed this was already a default

[segedunum]

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.

Jesus Christ..............

Re:I assumed this was already a default

[segedunum]

And tell your system you want that. You can change default config on Unix.

We have never needed to tell our 'system' that before. Plus, there are a long laundry list of commands (errrrr, everything a user has permission to run anyway) that a user can run that can be persisted. To have to 'register' them all is idiotic. Sessions != [necessarily] individual users, for good reasons, and to try and equate the two is just out and out stupidity. A system that restricts based on logins and logouts is totally broken.

Re: Well fuck you, systemd

[drinkypoo]

So you're saying that change through political means will result in a better outcome than technical ones?

You can't win technically unless it's with overwhelming technological superiority, especially against overwhelming numbers. We have to make a better world, because making a better fortress of solitude is harder than making a better bunker buster.

Re:I assumed this was already a default

[segedunum]

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?

Wow. Why ever would you want to do that? \sarcasm The systemd model is that everything you do starts after a login and ends with a logout. For those of us with experience this is stupid beyond words.

Re:I assumed this was already a default

[segedunum]

Probably quite a bit because no-one does any research on the issue before winding their neck out and making random ignorant statements especially as its just a configure change not a functional one.

A better suggestion would be that before systemd developers start making changes to default behaviour that has been around for decades, for good reason, that they actually work out why said behaviour was that way to start off with.

Sessions != individual users and login/logouts. Any system that does that has just gone backwards.

"systemd 230 now finally flipped the switch and finally by default cleans everything up correctly when the user logs out. But we do so in a very conservative way actually:

Which was done because the imbeciles couldn't fix Gnome and clean up its shit on exit. 'Very conservative' my arse. You've got to love the slippery political statements they spew out when they fuck up.

a) there's a compile time switch to turn this off globally (--without-kill-user-processes, not used in Fedora)

Wow, recompiling. Really helpful.

b) there's a runtime switch to turn this off locally on the system (in logind.conf)

Not default, expected behaviour.

c) there's a way to opt-out invidually for each user and each task from the cleanup logic, via systemd-run/loginctl linger. This operation goes through PK, and thus can be configured in a more strict or more open policy, depending on whhat the admin prefers.

Yay. I get to run through all the commands in /usr/bin et al and explicitly tell it I'd like them to persist - even though I'm already explicitly fucking doing that with nohup or something else because that's what those commands are for.

Re:I assumed this was already a default

[segedunum]

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:I assumed this was already a default

[sjames]

C runs under a restarter and the database re-connects on ENOTCONN. Done.

The restarter can be as simple as while true; do run; done. You'll probably want to echo something to a log in the restarter just so you can see how often it happens.

Re:I assumed this was already a default

[sjames]

Then why in your steps is there no save or restore of state?

Re:I assumed this was already a default

[lgw]

I remember when file-and-print servers were a big deal, but them I'm old. Nowadays, all the servers I work on are effectively single user. Oh, they'll do work on behalf of thousands or millions of end users, but none of those end users have sessions or accounts on the servers, they just send some bytes to port 443, or whatever port the server has open for the API it serves.

At most, there'll be one human actually logged in, to troubleshoot something, and if he needs nohup then nohup needs to work.

Re:I assumed this was already a default

[mysidia]

which means that the job of terminating the session when it's finished belongs to, err, umm, the init daemon.

No.... the job of terminating the session is The Shell's job. The session is terminated when the shell chooses to exit; Init is only responsible for starting/respawning processes and possibly passing signals through to the direct child process. If the user exits through means such as Hanging up their modem connection, then it's the kernel's job to signal hangup (SIGHUP).

And the Shell is responsible for Job Control: exiting the shell's child tasks.

The Init system or system daemon is Not responsible for Job Control; this is managed by tasks running under the user's identity.

Re:I assumed this was already a default

[segedunum]

yawn... Pen and paper used be the way to do things so whats your point?

Yawn..... It still works.

if you don;t like tightening up security on your systems, thats up to you.

What the fuck has this got to do with security, from someone who obviously knows squat about it?

I presume most of the anti are like the manual workers of old who were worried that computers would take away their jobs and in this instance systemd is taking away manual tasks from you.

Which has no relevance to what's being discussed. Bloody hell........ I'd recommend you stick to the recommended dose for whatever your meds are.

Re:I assumed this was already a default

[segedunum]

Same example I've given you. A depends on B depends on C depends on D depends on E. C crashes and the system is able to recover. What does the operating system do with A, B, D and E to get them aligned with the new state?

I've never encountered this scenario. You know why? Because it's hypothetical nonsense.

Tested, and proven.

[DrYak]

One, no one has credibly stated that screen/tmux are left alive. There are people reporting that screen/tmux sessions are killed.

I do.
On a stock Jolla phone, SailfishOS has the same clean-up option activated that the Debian systemd packager has activated in TFA.

If I type:
ssh jolla -t -- su -l nemo -c "'screen'"
My screen session survives without getting killed.

(Note:
- nemo is the main user on a Jolla smartphone.
- su starts this screen session in its own separate session (in a different CGroup, and all the various non-POSIX/Linux-specific seats & namespaces & containers, etc.)
(there's also a systemd-specific way to start a shell in a new sessions, using some "machinectl shell" construction, but su does the job and is more compact)

Or you, know, you could stop complaining on forum, turn the damn option "off" in Debian-Sid like virtually every single other distribution does, and file a ticket on debian's bug tracker to ask the packager to make back the default not to clean-up the session like everyone else is doing.
(and BTW, what are you doing complaining about Debian- Sid ? It's supposed to be unstable and rough edges by design. Things breaking under Sid like this are supposed to be common. Use some LTS distro if you want peace of mind).

Or if you want to go the systemd route, I would encourage you to read a little bit about the various "--user" option, and ".service" (and/or ".timer", etc.) syntax.
That will help you cover most of the "need process in the background" situation that aren't covered by screen's "I need my long-running computation to survive between ssh remote sessions".
(e.g.: for any end-user daemon).
I've managed to convert most of my background tasks this way on the various systemd-powered installation I've been using (openSUSE Leap 42.1, openSUSE Tumbleweed, CentOS 7, and Debian's own Jessie release which doesn't have the "KillUserProcesses" toggle set as mentionned for Sid in TFA).

Re:Tested, and proven.

[Junta]

Ok, so you are doing more than just running screen and detaching, you are using su in a certain way to circumvent. This again is not 'things work just normal' scenario.

If no one complains during unstable, then things are too screwed by the time testing rolls around, and then folks would ask "well if it were such a big deal, you should have said something before it got to the quasi-stable testing state, we can't risk changing things back *now*". If no one ever complained until it hit LTS, then people will get stuck with it for years instead of having their voice heard at a point in time that would actually mean something.

Re:I assumed this was already a default

[Guy Harris]

The point of systemd is process management. To give to Linux what Solaris, Digital Unix, AIX... have for big box. To give Linux what mainframes have (or at least some fraction of it) since Linux is replacing those use cases. And on the desktop to give Linux what Windows and OSX have.

One thing that all of the non-Linux UN*X systems you mention have is the notion that if you run some process under nohup, it'll continue running after you log out. (Tested on OS X 10.11.4 and Solaris 11.)

What some people are complaining about with this configuration change to systemd-logind is that, with that change, if you run some process under nohup, it won't continue to run after you log out, so there's one thing that Solaris, OS X, etc. have that you don't have.

Critical server on Sid?

[DrYak]

Anyone who's ever been disconnected from a server 2 hours into a 3 hour process knows the importance of using screen.

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

And even on distro with auto-cleaning-up activated in logind (e.g.: SailfishOS on Jolla), 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)

Re:Critical server on Sid?

[segedunum]

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

Not systemd, Linux

[DrYak]

Actually it stems not that much from systemd itself,
than from Linux being not POSIX, but having lots of extensions over it:
seats, namespaces, cgroups, containers, etc.

Systemd simply tries to manage them (there's no other tool that attempts to do it right now).

And BTW, quite the contrary, this kind of strict compartmentalization actually enables you to have *multiple* users using multiple *seats*.

E.g: having 3 users each running their own desktop environment on the same workstation, as long as the GPU has enough monitor outputs and enough USB keaboards and mice are plugged in.

Re:I assumed this was already a default

[segedunum]

You could have written a far shorter sentence that would would have listed something useful that systemd actually did.

Re:I assumed this was already a default

[segedunum]

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?

Th reason for this new default is because Gnome wasn't cleaning up after itself and no one could be bothered to find out why. Killing everything after logout was the only fix they could find: https://lists.fedoraproject.or...

Re:I assumed this was already a default

[segedunum]

and i posit that the security of knowing what is legitimately running on my system after log out is reason enough.

It's all about security now - from someone who doesn't know shit about it. The reasons for this farcical piece of nonsense change every minute. The initial reason is because Gnome couldn't clean up after itself.

Re:I assumed this was already a default

[segedunum]

This is hypothetical tripe where you won't be able to provide one single real-world example. Repeating it won't justify anything, alas.

Re:I assumed this was already a default

[segedunum]

Only the process manager has the global knowledge of the competing demands to make intelligent choices about resource allocation. Given competing demands for a system to work well intelligent choices need to be made about what should be running when. That's systemd's job.

That is utterly meaningless and simply shift the goalposts yet again as to why this change was made. I've lost count of the number of reason changes we've had. Security, resource allocation, wind blowing from the east........

Re:I assumed this was already a default

[segedunum]

no user process will be killed on exit/logout if the user have told the system not to.

Why would I need to tell the system? I didn't before and sessions != users.

Re: I assumed this was already a default

[Entrope]

A better person than you would be ashamed and admit their error and ignorance, rather than lamely accusing me of bad faith just because you can't answer the question.

Re: Well fuck you, systemd

[NotAPK]

"We have to make a better world, because making a better fortress of solitude is harder than making a better bunker buster."

Amen to that!

Re: misleading title as usual

[RightwingNutjob]

Let me make yet another attempt to explain it to you in simple terms: Neither you nor Poettering are king of the world and systemd is not a throne from which you get to dictate terms. Neither he, nor you, nor anyone else gets to make extra work for us (now and going into the future) by breaking the way things function and telling it that it's on us to manage two different and incompatible versions of the same code where before we had one set of code that worked fine.
>
Bullshit dictatorial attitudes like that is why I have never voted for a Democrat, why I will be voting Libertarian this year, and why I will be deliberately uninstalling systemd from my machines going forward, both at home and at work.

fixed in debian?

[lcall]

https://bugs.debian.org/cgi-bi...
says "The option has already be[en] reverted in the packaging git."

Re:I assumed this was already a default

[thegarbz]

Replace well-known things that are not broken

Yeah stopped reading right there. I mean it's not like there haven't been multiple attempts to fix linux audio and multiple attempts to replace init in the past. It's sad that when something finally sticks that people jump back on the "change for change's sake" or "it wasn't broken" excuse blind to the many many use cases that the old way didn't support because you think the OS should only ever work in the specific way you personally use it.

Re:I assumed this was already a default

[thegarbz]

Yeah it's almost like they need to give you the option to configure this behaviour. ... Oh wait that's no where near as fun as just complaining about a problem already solved.

Re:I assumed this was already a default

[RightwingNutjob]

You don't understand anything. Educate yourself by starting here: https://en.wiktionary.org/wiki...

Re:From a security perspective...

[Entrope]

People already did the work to keep their processes alive after their session leader exits. systemd is now breaking that work, apparently because GNOME's developers cannot figure out how to fix their own bugs, and must rely on systemd to clean up the cow droppings they leave all over the place.

Re:From a security perspective...

[Entrope]

nohup is only one way to perform the steps that allowed a process to keep running after the user logged out. It isn't hard to do the same things within a program when and if it was necessary. systemd has broken programs that do that.

For example, take a daemon that has command-line switches to make it check its configuration files for obvious problems versus running in the background. With this systemd change, the only fine-grained way to make it work the way it was intended was to add a lot of command-line noise to places where it is started in its daemon mode. The global and per-user switches will leave buggy software still running when the user logs out.

Re:From a security perspective...

[Entrope]

The other Unix slogan mentions re-implementing Unix, poorly. The systemd tools seem dead-set on living up to that one.

Re:I assumed this was already a default

[segedunum]

You don't understand what state is. Re-read your steps. There is absolutely nothing in here about how state is saved.

Re:Not a fan

[Entrope]

There was basically a choice to be made:
(a) Fix bugs in software that left processes unintentionally running past logout,
(b) Allow users to opt in to unconditionally killing processes on logout,
(c) Interactively ask users which process groups to keep, or
(d) BREAK ALL THE THINGS.

Only an idiot, an asshole, or an arsonist chooses (d), and I am inclined to think it's one of the latter two when they admit to knowing it will break things.

Re:I assumed this was already a default

[segedunum]

OS X and iOS does not save state the manner required I'm afraid so I don't know what you're talking about there. It's a ridiculously complex and rather silly thing to do when you can just persist processes when needed.

Automatic special case for gnu screen?

[Theovon]

Some people are saying that this new behavior is killing screen. Can’t systemd be configured to automatically recognize screen and not kill it?

Re:Automatic special case for gnu screen?

[Entrope]

systemd could be modified to do that, but it would still break tmux, dvtm, and millions of site-specific programs.

Re:I assumed this was already a default

[segedunum]

The principle of least astonishment is following systemd policies.

Policies which change every week, or change based on Gnome having bugs they don't want to fix ;-). That's the exact opposite of least astonishment, actually.

Re:I assumed this was already a default

[segedunum]

You have heard. Process management.

Which depends on kernel features. Why do I need systemd again?

Re:misleading title as usual

[Entrope]

The problem with your approach is that it doesn't fix the problems that this change is intended to address.

With KillUserProcesses=no, several GNOME packages keep processes running after the user logs out, when those processes should have terminated at the same time the user logged out. With KillUserProcesses=yes, systemd cleans them up instead. When people file bugs about the GNOME packages being buggy, maintainers will probably close them because KillUserProcesses=yes is the intended (and only supported) use case.

The people who expect standard behavior are hit twice: Once by having to specifically ask for that bog-standard, well-documented, entirely reasonable, behavior -- and again because some software expects their bugs to be worked around by the non-standard behavior in question.

Re:I assumed this was already a default

[segedunum]

This is the kind of convoluted crap I'd expect really, which again, has no real world basis because those sensible enough don't run something this stupid. Those that do run [very] unstable applications ;-).
You restart C under daemon tools or something, anything will do, and then reconnect the database. You also want logs to output when this happens. Creating a complex system to manage this is just insanely stupid.

Re:I assumed this was already a default

[segedunum]

I don't see people running long standing tasks after they log out of a PC as being a major use case and therefore it makes sense is the default doesn't allow it to happen.

You don't do any system administration on servers then.

Re: I assumed this was already a default

[segedunum]

I like being finally able to hedge off a part of my processes and manage their resources in ways that login sessions and process leaders don't provide.

Which.........you haven't managed to back up, and totally misunderstood what POSIX already supplies.

Re: I assumed this was already a default

[segedunum]

Because the alternative mechanism is better, IMO.

Alas, simply writing this over and over this won't make it true.

Re: I assumed this was already a default

[segedunum]

Eh. Wrong checkbox. That post was mine, if it wasn't obvious.

So you were wrong, can't admit it and have nothing to say? Errrr, OK.

Re:I assumed this was already a default

[segedunum]

The manual is rather incomplete and behaviour changes every other commit.

Re:Sorry, Slackware is NOT an option. Nor is Gento

[segedunum]

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.

I ran Gentoo for a long time and if you want to upgrade your distro sensibly, at this point recompilation is the only sensible option ;-).

Re:From a security perspective...

[segedunum]

Not a convincing argument I'm afraid.

Re:I assumed this was already a default

[segedunum]

.....and OS X also implement nohup properly ;-).

Poettering inventing limits

[Sepulep]

According to Poettering this is just a 'misunderstanding:' "The changed default here is really about defining the lifecycle of unprivileged code by privileged code, and thus about security" Logging out is not meant to invalidate your credentials of running code on a system - its just as arbitrary to make this the default behaviour as it is to automatically kill user processes at 00:00 or after 30 minutes of inactivity - I am sure this would also "improve" security. ...if the user is removed from the system - then, yes kill his processes.. the runaway processes argument is bogus - a runaway process is equally bad whether you are logged in or not...

Why not use a dialog prompt?

[lambsonic]

If any background processes are running, just pop up a dialog on logout and ask if they want them killed. No need to make assumptions.

Re:I assumed this was already a default

[Spacelord]

> If they want Potterix to work differently, they should put out a distro.

They have, it's called Red Hat Linux *ducks*

Re:Sorry, Slackware is NOT an option. Nor is Gento

[Etcetera]

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.

Frankly, what we need even more than Devuan is a fork and re-structuring of the RedHat ecosystem. Unlike .deb-land where the more dynamic Ubuntu is a downstream of the stabler Debian, the "upstream" of RPM world is the bleeding edge Fedora where this crap began with, not the more-enterprise-stable RHEL.

The unfortunately-named CentOS ("Community ENTerprise OS") is an intended binary-compatible rebuild of RHEL, so it really doesn't have the freedom to change anything at all and remain within its goals (even before it became part of RedHat). What's needed is a sane, more stable fork of Fedora.

It could be done... Start with CentOS 6 as a baseline, and bring this up to date with CentOS/RHEL7 tech (kernel, glibc etc.) using Scientific Linux 7 as a concept for rebuilding. Bring in stability features, while leaving out as a requirement what's generally a poor fit for a server, such as systemd as /sbin/init, NetworkManager, etc. It doesn't mean they're not there, but they're not forced. systemd can still run, it just isn't PID1... It's a service launched via script just like any other service manager (such as xinetd).

From there, build a server-quality distro that's broadly (generationally) compatible with the major release of RHEL, but is free to not do the stupid stuff.

RPM-world needs and deserves a new, server-class RPM-based distribution.

Re:I assumed this was already a default

[phantomfive]

Yeah, that's not going to happen lol

Re: I assumed this was already a default

[mvdwege]

That reading is about as correct as your understanding of systemd, taking into account Dunning-Kruger.

Re:From a security perspective...

[laddiebuck]

I don't. Thankfully my current distro, Mint, is one of the holdouts, even as Debian and Ubuntu have caved to the systemd madness. But how long are they going to hold out?

session

[cryptogranny]

I just don't get one thing. Let's look at OS that called Windows. It has two logout options. One to logout completely and kill all user processes and another that you can use remotely to keep your session and everything. Why do we have all this debate?? Linux session is what? Different by nature? Pardon my English.

Re:I assumed this was already a default

[jbolden]

Saving and restoring of state is something the process manager handles. Once the process manager knows what's needed it can decide how best to handle the problem.

Those aren't steps BTW they are options as indicated.

Re:I assumed this was already a default

[jbolden]

Why not? Why should Unix be forever unable to handle scheduling and resource contention in intelligent ways?

Re:I assumed this was already a default

[jbolden]

https://developer.apple.com/li...

Re:I assumed this was already a default

[segedunum]

Saving and restoring of state is something the process manager handles.

You *really* don't understand what state is.

Re:I assumed this was already a default

[segedunum]

You still don't understand what state is. Oh, and nohup works on OS X ;-).

Re:I assumed this was already a default

[segedunum]

To clarify, forcing applications to support state saving is *not* a solution because it doesn't preserve everything - TCP connections for one, as has already been pointed out to you somewhere above. We already have a solution - nohup, screen, tmux etc.

Nohup still works on OS X ;-).

Re:I assumed this was already a default

[segedunum]

Because it add a huge amount of complexity, requires application support and we already have simple and well established practices where these lessons have been learned. Decades ago.

Re:I assumed this was already a default

[segedunum]

What "ALREADY FUCKING WORKS"? Applications already receive notifications to save their state when the user is being logged out or "Windows style" simply loses anything that was active without notification?

Jesus titty fucking Christ. We background the process on logout and use the resources the user has already been fucking assigned anyway. Simple. No complex saving of state which wouldn't work anyway if you're using network connections. No new APIs. No new complexity. Done. Sorted.

Re:I assumed this was already a default

[segedunum]

Why would I need to configure behaviour I've always had?

Re:I assumed this was already a default

[segedunum]

Everyone would have been happier if one of the other solutions had panned out. The Linux community isn't used to someone just winning.

Not sure on what basis fucking up time and again is called 'winning'.

Re:I assumed this was already a default

[segedunum]

I don't see people running long standing tasks after they log out of a PC........

Bloody hell.

Re: I assumed this was already a default

[segedunum]

You obviously have no understanding of POSIX, no understanding of what Linux/Unix systems have had for decades, are actually describing a different solution as opposed to an alternative one and have shortened answers to "Because it is better" once you've been shown to be shooting your mouth off?

Sounds like a typical systemd argument to me.

Re:Sorry, Slackware is NOT an option. Nor is Gento

[segedunum]

The sensible arguments just keep getting better :-).

Re:From a security perspective...

[segedunum]

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.

Bloody hell. That would mean making sensible decisions and actually having a clue.

Re:From a security perspective...

[segedunum]

There is no change in how systemd handles either processes or logins with this change except that it purges processes that aren't explicitly allowed to continue to run.

That's an......interesting and political way of phrasing this. Unfortunately this is still a major change to default and expected behaviour even if you'd written it in Chinese ;-).

This is conceptually very similar to how things always have worked

No, it isn't.

....It is simply the way to explicitly tell the system a process is allowed to survive that have changed.

Squirm, wriggle, bullshit, bullshit. This means absolutely nothing. We had a way of telling a process to persist - it was called nohup and it worked very well. There is not one single good reason why this has been changed.

So please name me just one example of breakage or non-contrived stuff that are no longer possible to do with the new systemd settings?

Expected system behaviour. Even when you close a RDP session on Windows it is still there when you get back. It doesn't transparently disappear. There is not one single good reason why this should have been changed. We'll also find out what system administration scripts this inevitably breaks for people in the coming weeks and months.

There are several benefits from the new way of doing things too, like being able to use some of systemd's extensive resource management options.

You're making this up as you go along, aren't you?

Re:From a security perspective...

[segedunum]

Just edit your scripts.

This is why Linus had to tell the systemd people to go fuck themselves when they screwed up expected and working kernel and userspace interaction.

Re:From a security perspective...

[segedunum]

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

There's a few usual suspects that crawl on to these threads when systemd crops up.

Re:From a security perspective...

[segedunum]

i thought it was very obvious, security of your system and the security of knowing what is still running legitimately after you logout.

Except that wasn't the reason. That was a reason made up on this thread. The real reason was so Gnome didn't have to be fixed on logout.

Re:From a security perspective...

[segedunum]

No I don't. I just accept technically superior solutions as the way forward, even if they means another way of working.

Simply saying that won't make it true I'm afraid. As Linus said, we don't break userspace or expected behaviour.

Re:From a security perspective...

[segedunum]

Just lock the session instead of logging out. That would be the typical thing to do with a workstation since it runs a DE of some sort.

Jeeeeeeesus fucking Christ. Hey, instead of SSHing into a server what I'll do in future is to iLO into the console or something and run my scripts directly on the fucking terminal, eh?

If you wanted to see a systemd ignorance in all of it's idiotic nakedness, read that.

Re:From a security perspective...

[segedunum]

Well established Unix conventions, like using unencrypted connections (Telnet, UUCP, rlogin etc) that sends password in clear text?

Why are you using nonsensical comparisons to justify your total bullshit?

Re:From a security perspective...

[segedunum]

good grief. if all your scripts of 10 to 20 years are without any modification in any way, that's future proofing in the extreme. (or no updates at all)

Welcome to the harsh reality of the real world called "It fucking works".

Re:From a security perspective...

[segedunum]

Those are some pretty strong meds you're on if you don't think that this is changing existing behaviour. It's why Linus had to swear at systemd developers about not breaking userspace. Clearly that hasn't sunk into the thick skulls.

Re:Not a fan

[segedunum]

So because this idiot can't configure GNOME properly he decides that the entire world their servers needs to stop working properly.... and that screen/tmux should be reimplemented!?

Welcome to Linux userspace development today.

Headline is clickbait

[LichtSpektren]

This headline is completely wrong: "Systemd Starts Killing Your Background Processes By Default."

Unless you run a rolling release distro and you blindly update, you're not going to get systemd 230 without knowing it. (You could argue that it's still a problem regardless, but it's no bigger problem that Linux kernel/coreutil releases that have terminal boot errors and what not.) So this panic-inducing clickbait title is preposterous. It's nothing like how Windows 10 forcefully installs on peoples' computers with Windows 7 or 8.1 even if they deny the update.

Re:Headline is clickbait

[Junta]

It's a bigger problem than a transient boot error in a snapshot build of some subsystem. This is a declaration of a certain sort of intent that is meant to land in production systems at some point. It is evidence as to the opinion of the developers of the application, not some fluke mistake. It wasn't an 'ooops, we accidently killed user processes by mistake' sort of scenario.

The entire point of this reaction is to get opinions expressed one way or another before things have gone so far down the path that changing course *again* would just be even messier.

Re:Headline is clickbait

[LichtSpektren]

The entire point of this reaction is to get opinions expressed one way or another before things have gone so far down the path that changing course *again* would just be even messier.

That would be a nice point to emphasize. Some of the comments on this article are mouth-foaming at the thought of this change going through, as if the doomsday clock is two minutes to midnight and suddenly all your servers will be gobbled up by this abhorrent break. The reality is: the very worst case scenario is that you'll be inconvenienced for less than a minute if your distro-of-choice chooses to side against your preference and you have to manually edit the config file.

Re:I assumed this was already a default

[phantomfive]

That sort of thing makes sense on a batch system where you needed to schedule system time in advance. In the modern world where you don't have to worry about what other people are using the resources on your machine, there's really no reason for it.

Also, who uses FTP to do a slow transfer to a cloud? That's something you only do from a single-user machine.

Re:I assumed this was already a default

[Midnight Thunder]

What "ALREADY FUCKING WORKS"? Applications already receive notifications to save their state when the user is being logged out or "Windows style" simply loses anything that was active without notification?

Jesus titty fucking Christ. We background the process on logout and use the resources the user has already been fucking assigned anyway. Simple. No complex saving of state which wouldn't work anyway if you're using network connections. No new APIs. No new complexity. Done. Sorted.

If you are backgrounding all the process, why even bother logging out? What you are describing appears more along locking the screen than sending a message to the system that you are done. BTW MacOS X already provides a way of saving state and liberating resources, so it can't be that hard. It maybe well that the way that the way it has been implemented by systemd may not have been the best way, but there are certainly valid arguments from both sides of the proverbial fence.

Re:I assumed this was already a default

[sjames]

None of those options have a single thing to do with saving state. You show no sign of understanding what we were talking about. Please Google "saving program state" and "checkpointing".

Re: I assumed this was already a default

[mvdwege]

Yup, prime example of Dunning-Kruger in action.

Re: I assumed this was already a default

[rpresser]

"Calling a spade a spade" means using accurate, straightforward language instead of euphemism. If you honestly believe that Poettering is a female body part, I question your mental health.

Re:I assumed this was already a default

[thegarbz]

Because that's what happens when APIs change.

1. Create API.
2. Provide compatibility options for things that don't work with the API.
3. Set a new default.
4. New API is slowly adopted and compatibility layer eventually disappears.

We're at 3, and most of slashdot is bitching because they don't understand 1 or realise that the concept and the reasons for the change actually predates systemd development.

Re: I assumed this was already a default

[segedunum]

Right back at yer.

Re:I assumed this was already a default

[segedunum]

Because that's what happens when APIs change. 1. Create API. 2. Provide compatibility options for things that don't work with the API. 3. Set a new default. 4. New API is slowly adopted and compatibility layer eventually disappears. We're at 3....

Are we really? I'd love to know where the compatibility options are since this breaks default behaviour and isn't compatible, but then, we have a lot of raving nutcases around who don't understand these things at all these days. The problem here is that this change was pulled out of the blue because no one could be bothered to fix Gnome and no one actually has a plan at all. People are now performing mental gymnastics to justify it. It really is something to behold.

We have a lot of laughable numbskulls like the idiot above trying to claim there is some sort of grand plan and reasoned argument for this.

Re: I assumed this was already a default

[mvdwege]

Parroting shows a complete lack of creativity. You posting it shows you don't recognise that. Thank you for proving the point: you're wearing the juice.

Re:I assumed this was already a default

[jbolden]

What do you mean no batch in a modern world? Most of the world is still batch. For example the whole big data push is essentially cutting hardware costs and thus allowing for larger batch systems, going back to tape paradigms on hard drives using generic hardware. Obviously there isn't much one can do that's too intellegent other than avoid fragging with resource contention on real time.

As for a slow FTP taking 12 hours and wanting to suspend, I agree stupid use case. But I was saying that if such a thing were important than systemd should be extended to manage and schedule it.

Re:I assumed this was already a default

[jbolden]

Checkpointing is an application function. Other than notifying the application or dumping all of memory how is a process manager going to checkpoint?

Re:I assumed this was already a default

[jbolden]

winning = increasing market share.

Re:I assumed this was already a default

[jbolden]

Done really? C's lost information about D. B has lost information about the new state of C. They weren't notified in your solution. How is that done?

Re:I assumed this was already a default

[DrXym]

Thanks but I do. It is reasonable to clean up a user's mess when they log out unless there is an explicit reason not to.

Re:I assumed this was already a default

[DrXym]

It isn't a major use case. Please explain to me why it's so common that it should be the default behaviour.

Re:I assumed this was already a default

[RavenLrD20k]

I've not been able to test this myself as of yet, however there are multiple times in this very thread that state that this new change to the way systemd operates explicitly breaks tmux, screen, and nohup. I've done some cursory research on a google search and this does appear to be the case. Especially damning is this thread where it seems the workaround is to use a completely new command structure to create a long running process. If anything, the systemd team is breaking the old adage "If it ain't broke...".

Seriously; a change to the fundamental way a system handles user processes cannot be taken lightly. This new behavior is fine for a desktop machine where there'd only be a single user. For a server with multiple users that may rely on background processes to complete long running computations this very much breaks the expected behavior; and can quickly become a sysadmin's nightmare when users begin complaining that their processes are no longer staying active.

Re:I assumed this was already a default

[phantomfive]

For example the whole big data push is essentially cutting hardware costs and thus allowing for larger batch systems, going back to tape paradigms on hard drives using generic hardware.

I've spent a lot of time working with big data at various levels, and I'm still not sure what this means. Are you talking about column oriented databases?

Re:I assumed this was already a default

[sjames]

Obviously, C knows because it gets restarted after the crash. The ENOTCONN is the notifier for B and the new instance of C connecting to D is the notifier to D. How hard is that?

BTW, ":done" is clearly part of the do..done block associated with "while" in the script. The semicolons are the give away there.

If any further notifications are needed (they normally shouldn't be necessary in a good design), the script can fire them off.

But honestly, all of that is really just papering over bugs in C. Programs shouldn't crash.

Re:I assumed this was already a default

[sjames]

Grab the process via PTRACE, for example.

The reason checkpointing is typically done by the program itself is that there is sufficient complexity involved that it is a rather specialized operation. There is no generalized way to save a program's state (including system state and potentially, the world's state) such that it can be restored successfully. That is exactly why I rejected it as a solution.

Checkpointing *IS* saving state. I hope you now see that not only is there no process manager that saves state, no process manager CAN arbitrarily save state.

I have worked on systems such as bproc that narrowed the parameters down enough to *OFTEN* work, but there were always corner cases.

Defaults

[Etcetera]

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.

Your comment is wrong.

Debian didn't *intentionally* change the default. Systemd did. Debian failed to catch/care/notice/revert the change. This happened with Fedora as well (well, rawhide, Fedora's rolling unstable branch).

When you add in the systemd project's stated intent to make it more and more painful to NOT use the systemd defaults across the board (cf. https://lists.freedesktop.org/archives/systemd-devel/2010-September/000391.html), mincing words about distro-level deviations from upstream is not a very compelling response.

Re:Defaults

[jbolden]

Are you sure the change originated with systemd I had heard the opposite.

Re:Defaults

[Etcetera]

Are you sure the change originated with systemd I had heard the opposite.

Fedora/Rawhide was affected as well. The default was changed in 230:

Changelog

* systemd-logind will now by default terminate user processes that are
                    part of the user session scope unit (session-XX.scope) when the user
                    logs out. This behavior is controlled by the KillUserProcesses=
                    setting in logind.conf, and the previous default of "no" is now
                    changed to "yes". This means that user sessions will be properly
                    cleaned up after, but additional steps are necessary to allow
                    intentionally long-running processes to survive logout.

                    While the user is logged in at least once, user@.service is running,
                    and any service that should survive the end of any individual login
                    session can be started at a user service or scope using systemd-run.
                    systemd-run(1) man page has been extended with an example which shows
                    how to run screen in a scope unit underneath user@.service. The same
                    command works for tmux.

                    After the user logs out of all sessions, user@.service will be
                    terminated too, by default, unless the user has "lingering" enabled.
                    To effectively allow users to run long-term tasks even if they are
                    logged out, lingering must be enabled for them. See loginctl(1) for
                    details. The default polkit policy was modified to allow users to
                    set lingering for themselves without authentication.

                    Previous defaults can be restored at compile time by the
                    --without-kill-user-processes option to "configure".

Re:I assumed this was already a default

[sjames]

Certainly, I did no such thing. It didn't help that Gnome drank the cool aid and started depending wherever it could. Personally I'm fully ready to dump gnome if that's what it takes.

If you're claiming I should be maintaining my own private distro, I'll just say give that a try and report back, I could use a laugh.

Re:I assumed this was already a default

[exomondo]

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.

So don't accept the change, it's Open Source so these things are not forced on you, otherwise you might as well be using proprietary closed-source software.

Re:From a security perspective...

[exomondo]

The problem being that after years of struggling with unsupported OSes, RedHat managed to represent a hardware vendor friendly option that did pretty much what we wanted.

At the time that presented good value as a short-term gain, the problem was that this meant RedHat were the ones controlling the upstream. Nobody was interested in thinking ahead with "maybe RedHat won't always act in our best interests".

Fork and move on is not something the hardware vendors (and by extension, large IT organizations) will go along with you on.

I disagree, the hardware vendors are not dependent on systemd so they don't need to go along with you.

So there are zero supportable new Linux distros that provide the non-systemd experience.

I'm not sure what you mean by "new" but Gentoo and Slackware are just fine.

This is a big problem in and of itself, but also an indicator that there really isn't meaningful choice in distributions as they all just copy RedHat's moves now (even though Ubuntu, by install count far outnumbers them, RedHat still has the muscle by virtue of revenue).

Well no, that's wrong. As Devuan progresses and we see Gentoo and Slackware without systemd the only problem is people desperately clinging to RedHat despite multiple viable alternatives.

Re:I assumed this was already a default

[jbolden]

I guess my first question is have you done mainframe? If I say something like central Kentucky horse region looks like England that only makes sense if you know rural England. Anyway columar isn't particularly mainframe. OTOH map/reduce is. The core idea of MR is to able to process records individually and the consolidate aggregates, unlike relational's table at a time. That's exactly what mainframes databases do. Or for example you can think of Kafka as a bank of tapes. Etc...

Re:I assumed this was already a default

[jbolden]

You haven't solved A and E. Which shows how hard it is. An OS has to deal with programs crashing. It doesn't matter whether you think they should or shouldn't what matters is they do.

I don't know what you mean by .done and ... I think you are responding to someone else.

Re:I assumed this was already a default

[jbolden]

Of course no process manger can arbitrarily save state. What a process manager can do is ask complex programs to save their state and for simple programs save state. It can provide services to make it easier on programs to handle saving state (like simple key value data stores).

Re:I assumed this was already a default

[phantomfive]

I guess my first question is have you done mainframe?

Nope haha, just studied them. That's not entirely true, I have worked on them, but not enough to gain experience worth talking about.

nyway columar isn't particularly mainframe. OTOH map/reduce is. The core idea of MR is to able to process records individually and the consolidate aggregates, unlike relational's table at a time. That's exactly what mainframes databases do. Or for example you can think of Kafka as a bank of tapes. Etc...

That's interesting.

Re: I assumed this was already a default

[segedunum]

Right back at yer. Notice you're not discussing the topic you know nothing about anymore? ;-)

Re:I assumed this was already a default

[sjames]

It's not at all hard. A and E don't need to care because they weren't attached to the dead process. They haven't lost state with their dependent or their dependency.

In case they aren't properly designed though, that's what SIGUSR1 and SIGUSR2 are for. Or any failed process causes a script to be called that tears it all down and re-starts it. Set the starter scripts to trap any abend.

You said:

Done really?

and since my only use of the word was in a one liner script, I concluded you referred to that.

Re:I assumed this was already a default

[sjames]

If the simple program is talking to a remote server, it can't necessarily save state at all. How would you save state for netcat, for example?

If a file might change while the process is saved off, havoc could result. What do you suppose happens if vi (or emacs, or whatever) gets saved off just as it is about to write out a changed file? Then the file changes, later the editor wakes up and overwrites the committed changes.

Re:I assumed this was already a default

[jbolden]

netcat is the sort of thing that likely you would want to "save state" by recording running commands and reissue.

The best way to save state for an editor is to have them write the file out during save of state for the reason you mentioned. This sort of autosaving is for example implemented in OSX for precisely the reason it allows the process manager to decide between multiple potential editors. The other possibility would be to save state by
a) If the file is unchanged allow the editor to reload
b) If the file has changed, dump the contents. Since both emacs and vim maintain a temp file they will make the temp version available on restart.

Re:I assumed this was already a default

[sjames]

Yes, and now the editor suddenly needs specialized code in order for state saving to not be a disaster. Seems like it would be better to just send it SIGHUP.Best solution, run the editor in screen if the connection is at all likely to be broken in mid-session. Have the system honor the well known and long documented API.

The netcat example will fail. Remember, the other end of that connection didn't save state.

Re: I assumed this was already a default

[mvdwege]

Here's a cracker, Polly.

Re:I assumed this was already a default

[segedunum]

Using Linux on servers isn't a major use case. Rrrrrrrright...........

Re:I assumed this was already a default

[segedunum]

Thanks, but you don't. You also misunderstand how this works. Logout does clean up child processes - unless you explicitly tell the shell not to, which is what nohup etc. are for. You haven't the faintest idea what you are banging on about.