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

Rapists

[Anonymous Coward]

They are racist, xenophobic, Islamophobia, rapists, misogynists, warmongering, fecal demons.

Re:Rapists

[stooo]

Systemd is a pain.

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: Rapists

[Anonymous Coward]

Can you name one of these users who wants everything to stop when they log out? That's not how my cell phone works.

Re: Rapists

[Dr_Barnowl]

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

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.

Re:Rapists

[Anonymous Coward]

> Debian's config for systemd changed a default.

Thanks for the clarification.

In this case, it's goodbye Debian for me after all these years.

At least until the installer asks me whether I'm setting up a server or a desktop, and sets the systemd configuration (and other stuff) accordingly.

#systemdDeathSquads

[Anonymous Coward]

Trending 3.. 2.. 1..

Thats demonic

[Anonymous Coward]

No, really.

Re:Thats demonic

[Anonymous Coward]

daemonic?

Re:Thats demonic

[Anonymous Coward]

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

Re: Thats demonic

[Anonymous Coward]

Fucking genius

Re:Thats demonic

[Anonymous Coward]

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

Except daemons by their very nature "linger" so they're safe.

Re:Thats demonic

[arglebargle_xiv]

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

Re:Thats demonic

[shutdown -p now]

And ate my cat.

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

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:Thats demonic

[shutdown -p now]

Man up already.

Re:Thats demonic

[arglebargle_xiv]

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

Re:Thats demonic

[Anonymous Coward]

Systemd, the ultimate weapon for killing daemons, developed with the blessed collaboration of the Catholic Church and the Bible Belt. Because at some Epochs it is important not to be nice!

Re: Thats demonic

[Anonymous Coward]

Then your cat was a pussy ;)

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?

[Anonymous Coward]

In your mind. Then write your own drivers.

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?

[Curunir_wolf]

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.

Yea, you need to blame the lackeys that package the masterful creations - not the genius masters of the Linux operating system corrections team who use their superior talents implementing software to realize their glorious vision.

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?

[Anonymous Coward]

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.

Depends. Many packages just polish what the source author provided, possibly adding a couple patches typically for additional bugs they feel are needed.

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?

[Anonymous Coward]

Windows has the option to switch users / return to login screen without logging out.

This addresses your problem pretty easily.

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

Re:security best practice?

[Barsteward]

its all down to configuration so its up to you

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?

[Anonymous Coward]

In my mind my computer should do what I have told it to do, even if it doesn't think that is a good idea.
If I have told it to run a process it should keep running that process until it is done or I tell it to stop.
I don't want my computer to decide to shut down processes on arbitrary times like on logout (That may or may not happen when the screensaver starts.) or to suddenly decide to install Windows 10.

My computer should not do decisions for me.

Re:security best practice?

[Anonymous Coward]

This is where the problem is. POSIX defines a set of rules to disasociate the application from the controlling terminal, to allow it to continue running after the controlling terminal closes.

Various applications (including nohup, screen, tmux) corrently implement these rules, in order to allow tasks to continue running after logging out.

However, other developers write badly behaved user daemons that use these same mechanisms - but these daemons do not exit correctly when they are no longer needed.

Systemd's response is to simply break the POSIX spec, and kill of everything - including those tasks correctly marked to continue execution. Systemd developers then say that tmux, screen, nohup, etc are all broken, and must be updated to use systemd's internal flagging system.

This is absolutely incorrect. The misbehaving gnome user daemons are the ones that are faulty and need to be fixed. Why should other developers need to 'fix' their correctly implemented and perfectly behaved applications to make them work?

Re:security best practice?

[Barsteward]

configure systemd to allow tmux to stay up - RTFM

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?

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

Indeed you don't know. One does not detach from the controlling terminal accidentally. Normal background processes (those you start with & on a terminal) will be taken down when their terminal group is shut down. An explicit detachment from the controlling terminal means exactly that the process is to be considered ending asynchronously and under its own control, like when invoked with the nohup command.

Now you need to tell systemd that you did not do by accident what has to be done deliberately. That's just stupid.

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?

[Anonymous Coward]

Define admin level process? The only admin on a server is root and it is a bad idea to run daemons as root, right? So we run or daemons as non-root as best practice. Now, I then go in as my non-root user and make a few config file changes and then log out. And BANG! systemd goes and kills my daemon? Huh? That doesn't make sense from a best practice perspective.

Maybe the systemd developers need to get away from linux on laptops and look at how linux servers are run.

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?

[Anonymous Coward]

>

Maybe on your workstation. Maybe. On a server you pretty much want your applications running regardless if the process owner is or ever was logged in. An no, that doesn't mean the ID owning the process should have any root or admin privileges. Under the principle of least privilege the id owning the process should have only the privileges required to perform it's function. That's best practice when it comes to security.

Re:security best practice?

[Anonymous Coward]

Clearly the "systemd way" to fix this is to roll nohup and screen into systemd. Problem solved!

Re: security best practice?

[Anonymous Coward]

Fuck systemD and that asshat Poettering.

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?

[Anonymous Coward]

It's not even just an issue of logging out, what about network issues? Anyone who's ever been disconnected from a server 2 hours into a 3 hour process knows the importance of using screen. Not to mention the benefit of allowing co-workers to monitor the status of a process using a shared session. Closing a terminal while processes continue to run on a remote server is standard practice.

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?

[Anonymous Coward]

I'm a package maintainer of another distro, and something like process supervision -- a *core* part of systemd -- is something I would absolutely test. The first thing a maintainer should look at before releasing a new version of a package is the changelog of upstream's work. Barring that, if you're the least bit savvy you can clone the source and do a `git log`. Or do a diff.

If this logind.conf setting was changed by default, it would have shown up in a diff. That said, systemd is much like GNOME in that it's a hard project to follow, and I feel sorry for any maintainers that have to manage that tripe.

Re:security best practice?

[Anonymous Coward]

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

That latter part is particularly worrisome, too. Granted, it usually *is* a good idea to follow upstream, but that's because most upstreams don't give a shit about agendas and just want to make good software. Projects that have agendas, on the other hand, should definitely have their suggestions scrutinized.

The 'nu Linux' culture of "just follow upstream" is at odds with the entire point of distros in the first place. Distros exist to form collections of packages, and they often have _opinions_ on how those packages should be installed and/or worked with. That's a great deal of why distros like Gentoo and Slackware (both usually adhering to "maintain user choice and flexibility" as their mantras) are still around and still relevant: they have an opinion and they exert it.

Re:security best practice?

[Anonymous Coward]

Because it all ties back to the big gorilla of the Linux world, Red Hat.

core devs of both systemd and Gnome are RH employees.

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?

[Anonymous Coward]

its all down to configuration so its up to you

Just whack the mole if you don't like it.

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?

[Anonymous Coward]

Well actually it was the Gnome devs he was referring to as lazy morons

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?

[Anonymous Coward]

Mod Parent Up!!!

I don't care about the code quality: those other factors make it a cuckoo in the nest. And despite all this, as you say, it's still being adopted. Sigh.

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?

[Anonymous Coward]

Possibly, but when they do it will no doubt be the new systemd-rundetachedprocessafterlogin command that takes the --username, --passwordfromprompt, --detachedprocesscommandpath and --detachedprocesscommandpatharguments parameters, so that it can be a properly "secured" process yet still fit into the half-Unix half-PowerShell mutant that is the systemd namespace.

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.

Re:security best practice?

[Anonymous Coward]

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.

The only lazy person I see on here is you.
How about, rather than bitching about something you so obviously understand nothing about, you actually learn why having client software control itself is a freaking bad idea?

nohup doesn't even allow you to properly reconnect to the parent process and you have to manually make sure that any output is captured correctly.
daemon(3) (which is what screen uses) also allows user programs to daemonise themselves (what do we have an init system/system manager for again?) and communicate with the shell directly.

Both of them are complete and utter lunacy. If you think otherwise, you ought to stay away from any sensible computing.

Re:security best practice?

[Anonymous Coward]

...and the fact that, despite all this, it's still being adopted.

SELinux failed as the NSA's backdoor into Linux systems. But the monolithic, slipshod, all consuming disaster that is systemd can be that backdoor!

Re:security best practice?

[Anonymous Coward]

The problem is that, historically, Unix-like systems have conflated two different events: 1. the terminal (or terminal emulator) is disconnected 2. the user logs out of a session.

In the pre-GUI era, it was fine to conflate those because it wasn't possible to do one without the other. In either case you send a SIGHUP, and if you want the process to persist you just have to have a handler for it. But GUIs change everything - if you are logged into an X session with multiple terminal emulators open, run a process in the background of one of them, and then close that emulator window, do you know what happens to the background process? Answer: it depends on the emulator and on the shell whether or not a SIGHUP is sent to the process. If you want to guarantee a process survives its parent terminal closing, you have to handle SIGHUP - but then it would also handle the SIGHUP from logging out of the session, as well, causing it to stick around as a zombie process and potentially a security risk.

So you have three options - if you want to keep SIGHUP for logouts, then you have to change the behavior of programs that are supposed to exit if the parent shell or window exits, which means at a minimum changing the behavior of all the shells and terminal emulators out there. If you want to keep SIGHUP for terminal disconnects, you can keep shells and terminals the way they are and require programs that want to survive logout do something differently. Or you can get a new signal type added to the Linux kernel and use that for logging out, but even though that's probably the simplest method (change a few header files, mostly) it's also the least likely to happen. In that case it's clear which of the other choices will require the least changes to other projects, so it makes sense to do.

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.

I assumed this was already a default

[WarJolt]

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.

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

[Anonymous Coward]

Shut the fuck up Grandpa!!! Get out of our basement and/or die already!!!

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.

Re:I assumed this was already a default

[Anonymous Coward]

Apperently this only became an issue now that you can find systems with many Gb of RAM in a dumpster.
Having a sysadmin costs too much?

Re:I assumed this was already a default

[Anonymous Coward]

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

There is CRIU: https://criu.org/Main_Page but the Systemd Cabal is trying its hardest to forget about its existence, so you should expect it to break mysteriously when using it on a systemd system. On other systems it'll work just fine.

Re: I assumed this was already a default

[Anonymous Coward]

Dad, seriously, you need to pay rent or get out of my basement. Enough is enough.

Re: I assumed this was already a default

[Anonymous Coward]

No! My post got modded Insightful! People like me here you faggot!

Re:I assumed this was already a default

[Anonymous Coward]

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

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

Re:I assumed this was already a default

[Anonymous Coward]

Ah, yeah - and the admin *can* decide, since this is easily configured from logind.conf.

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.

Re:I assumed this was already a default

[CanadianMacFan]

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

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

Re:I assumed this was already a default

[sjames]

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

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

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

Re: I assumed this was already a default

[Anonymous Coward]

Dad, please. Slashdot is a bunch of old weirdos, get off the computer and go get a job. Mom died 5 years ago, you need to get over it and get off this site.

Re: I assumed this was already a default

[Anonymous Coward]

If you ask my employer, yes. They are constantly telling me that as a Sysadmin that my colleagues and I will be surplus to their requirements in a short time, and yet their clueless devops people are incapable of building a system that doesn't need us.

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

[guruevi]

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

Re:I assumed this was already a default

[Anonymous Coward]

Never was before.

It used to be that terminating the group header process would terminate its children. To bypass that used nohup to establish a new process group header and disconnect from the existing stdin/stdout/stderr.

Once nohup was used, long running things worked just fine.

If you wanted to limit the resources a user could use - limits.conf at login.

Re:I assumed this was already a default

[Peter H.S.]

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.

A good thing that you are misunderstanding what is happening then; 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.
This is how you start "screen" so it will survive logout: "systemd-run --user --scope".

Re:I assumed this was already a default

[Anonymous Coward]

Please tell me what systems you admin so I never have the slightest chance of accessing?

And what if I lose connection? Are Ubuntu / Debian "admins" seriously this far out of touch with reality they've never heard of ssh?

Capacha: apology

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

[Anonymous Coward]

Or they *can* decide not to use systemd. Or Debian if they don't revert the default that systemd changed. Because to say "this is easily configured" doesn't justify changing a default that has obviously adverse effects without some more solid justification than some vague notion of what's good for the user. 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.

Honestly, changing expected behavior like this should minimally come with a big warning and be carefully considered. No amount of claims of a new API to work around this feature is really adequate. And the GP's post just doesn't represent any experiencing using *nix, so his assumption is well, irrelevant.

PS - You might think this is very "baby out with the bathwater" and alone I'd agree. But if this happens again, one really should reconsider using systemd. Who knows what they'll change next for the user.

Re: I assumed this was already a default

[Anonymous Coward]

What the fucking bloody hell was wrong with how it worked before the systemd fuckheads got involved?

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.

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

[Anonymous Coward]

And the even better thing is tmux. Just sayin'. I would be really fucked off if my system killed my tmux (and therefore my ircssi) and my emacs server when I logged out.

Re:I assumed this was already a default

[Anonymous Coward]

Shouldn't those sims run as their own user, rather than under the user who started them?

Re: I assumed this was already a default

[Anonymous Coward]

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

Well, we still can; I will always refuse to use any distribution that comes with systemd installed. I don't care what that gaping vagina Poettering thinks, there's nothing fundamentally wrong with svr4 and whatever "problem" systemd aims to "solve" simply doesn't exist to begin with.

Re:I assumed this was already a default

[fluffernutter]

That's what background commands are for. man nohup

Re: I assumed this was already a default

[rpresser]

There are literally thousands of nonsexist insults you could have and should have used. Choosing the words you did greatly weakens your own credibility.

Re:I assumed this was already a default

[Gavagai80]

If the machine is for your personal use, I'm curious, why are you logging out? Personally I never logout except to reboot.

Re:I assumed this was already a default

[Peter H.S.]

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?

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.

Re: I assumed this was already a default

[Anonymous Coward]

But you've listed none of those insults for him to grow and learn from (dammit - ended in a prep!)

CAP === 'shipyard'

Re: I assumed this was already a default

[Anonymous Coward]

Go be a white knight somewhere else. There are probably some fair maidens at Github you could be defending right now.

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

[Anonymous Coward]

What's sexist about calling a spade a spade?

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

[Anonymous Coward]

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

I maintain a whole pile of them. Running long running models in the background by any number of users.

> screen is a program that explicitly survives logging out

and (apparently) this change will kill the GNU Screen process, and any long running jobs spawned in or out of it, when the user logs out.

I don't know how much truth or fallout from this there will be, but the Systemd maintainers have proved themselves to be myopic jerks many times in the past so I wouldn't be surprised.

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

[Anonymous Coward]

It's up to those apps to determine what is the right thing to do upon recieving SIGHUP.

No that's the same folly of co-operative multitasking. The user decides, not the program. The user does so by changing the default value in logind.conf or by using nohup. Or you can just not use systemd, if you dont like it then dont use it. You dont need to be beholden to RedHat's whims, that was a choice of convenience, yes it requires significant work to decouple but there was a signficant backlash by a supposed large number of people willing to engage in a lot of whining and complaining but not willing to actually do anything about it.

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.

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

[Anonymous Coward]

Back when I was reliant on uni servers for big simulation runs I would log in, start a screen session, set it going, detech the screen and log out. Every few days I would log back in to see if it was done. If I'm understanding this change correctly then I would need to stay logged in the whole damn time (sometimes for weeks non-stop) under this new policy, which is (a) damn inconvenient and (b) statistically unlikely given how long your average adsl modem stays up, even if I could disable autologout after x minutes etc.

Re:I assumed this was already a default

[Anonymous Coward]

Doesn't really work if you have some major number crunching to do though. In that case you want to set it going, log out and leave it run while you do other work, then log back in in a few days time when it might have finished. Right now screen lets me do that. Under the new system, though...

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

I have to do an extra step on top of running screen and you're telling me that's not a problem?

Fucking craptemd shills.

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

[Anonymous Coward]

Why do you think you're not a retard? Is it something somebody told you, or are you just presenting what you imagine as facts?

Here's a hint: It's not our job to prove that there's no solid reason for this change. All systemd supporters have to do is produce one.

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

[Anonymous Coward]

Bzzt. The expert user is exactly the type of person who can go into Chrome flags and turn the legacy backspace == back function on again. Or use one of many options available on their chosen platform of Linux, Mac, or Windows to remap the key(s) of their choice to send the input of their choice (here: Ctrl or Alt + Left Arrow) while $browser is the active window.

Speaking as a seasoned veteran, I can tell you I truly hated the backspace feature and am thoroughly pleased there will be a (default) option to turn it off. Nobody sanded all the corners off your stuff, this is one browser maker making a data-based UX decision.

(And shouldn't ultra power users be using Lynx, or like, taking in raw TCP streams encoded as vertically scrolling Matrix code?)

Re:I assumed this was already a default

[Curunir_wolf]

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.

What the ... ?? Is this a troll? You can't be serious. C'mon - what the hell is this shit? OMG - REALLY? Wow - there it is. Crazy.

Somebody needs to get Pottering a girlfriend or whatever. He's going nuts. Who's paying that guy, anyway? Maybe a government job.

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

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

[Anonymous Coward]

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 never said it would be easy but since you decided to hitch your cart to RedHat you are at the mercy of their choices, you made a poor decision and it has come back to bite you.

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

[Anonymous Coward]

You mean other than forking off Devuan, for example?

No I mean exactly that. Instead of whining about systemd how about contributing to (donating time or money) the Devuan effort? (not just you but the legions of complainers that populate all things related to systemd)

Re: I assumed this was already a default

[Anonymous Coward]

No shit, Sherlock. This update *breaks* nohup.

Re: I assumed this was already a default

[Anonymous Coward]

his head just exploded. headless system? he never heard of that before for he is a baby.

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

[Anonymous Coward]

What about people who are compiling code or computing things or whatever for hours/days in their user space and get disconnected or want to check from elsewhere?

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

[Anonymous Coward]

That is not dead which can eternal lie, And with strange inits, even screen may die.

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.

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.

Re:I assumed this was already a default

[Barsteward]

RTFM on systemd configuration and you should be fine.

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

[Anonymous Coward]

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.

Well, I can't really vouch for mediocre people with Asperger syndrome, but I tend to be on the ultra-conservative side of programming, fixing the implementation but keeping behavior/API whenever possible. Everything else implies imposing and defending decisions. I really hate having to break uses that worked before. Of course, part of the reason for that is that I hate dealing with people reporting problems (well, maybe so do the systemd developers but they deal with it differently than I do, apparently). I rather try casting previous existing behavior into a coherent system and then streamlining, documenting, and extending this system where it becomes something people recognize and feel confident about with some justification, feeling that they are finally understanding the underlying principles even if I sneaked the principles into the system post-haste.

At any rate, I don't think Asperger's syndrome can be placed at fault here. Even while its symptoms include a lack of empathy, breaking working systems is not something that would be all that typical, even taking the constant "this was not working properly" drone of the systemd developers into account.

Re:I assumed this was already a default

[Anonymous Coward]

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.

Not at all. A stopped process image is nothing but a perfectly saved state. Which gets us back to the question of why systemd should be allowed to kill it.

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

[Hognoxious]

Nein, it fixed nohup. nohup voss wrong, wrong, WRONG!!!!

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

[Anonymous Coward]

Will you come over and check and fix all my old scripts and possibly binaries that invoke background stuff?

Thought so, and I have better things to do, too.

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

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

[Anonymous Coward]

How many "multi user" systems are left anymore anyway? Practically every machine I log into these days is dedicated to my personal use.

Have you heard of "servers"?

Including home servers, of course. I and my wife use personal computers, sure. But anything important is stored on a home server. (Desktop machine running linux, samba, ssh and a mailserver) A lost PC won't loose any important data, that is the idea. Also, we can transfer files without resorting to dubious third-parties like dropbox. A local server works even if the Internet connection is down too.

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.

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.

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

[Anonymous Coward]

It wasn't confusing, it was fucking annoying when focus was lost on a text field and you backspaced to the previous page by accident.

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

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

[Anonymous Coward]

Why should your fucking mother love you /unconditionally/?

It's part of becoming an adult that you learn how to behave, that your actions have consequences, and that nobody owes you unconditionally anything.

As to systemd, what is the PORTABLE way of not having your process killed on logout? Or is systemd (and the crappy, broken, undocumented dbus interface) the new gold standard we should hold up to?

Re:I assumed this was already a default

[Anonymous Coward]

I have yet to hear of anything systemd can do that wasn't already being done

That's because when people try to tell you things systemd can do that couldn't be done before, except with massive amounts of spit and baling wire, you put your fingers in your ears and go "LALALALAAA! I CAN'T HEAR YOU!!".

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

Re:I assumed this was already a default

[Anonymous Coward]

Why should I? Last time I tried you didn't listen. You're just an old dinosaur, and eventually you will die off. In the meantime I shall enjoy myself by insulting your worthless hidebound presence on these threads.

Re: I assumed this was already a default

[Anonymous Coward]

I am getting a distinct impression from your responses here and in the rest of the thread that you are not asking in good faith. So without further ado: have a nice day.

Re:I assumed this was already a default

[sjames]

Since it would have been easier to name one, I conclude you have no idea.

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

[Anonymous Coward]

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?

the 'ulimit' limits (which pam_limits is setting) are inherited by child processes; a child process will not have its limits lifted just because its parent died.

go read setrlimit(2)

there's no magic involved there; the login process is simply setting some limits for all processes descended from it; the pam_limits module just make that configurable via the limits.conf file.

the 'session' thing is just a pretentious way of saying that a process cannot set limits for other processes that are not itself and its descendants.

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.

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

Re:I assumed this was already a default

[Anonymous Coward]

And how would that work with a process that might be connecting to a remote system to fetch data?

If i tell the system to keep something running (from my current shell) it should keep it running... Not just terminate it..

If they want to clean up gnome processes, and want to do it in a way like this each process that should be terminated should have to register to systemd to be terminated, not the other way around.
Forcing one messed up project to add code to do a proper cleanup is one thing. Forcing *ALL* process into this braindead scheme is just bad.

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.

Re:I assumed this was already a default

[Anonymous Coward]

And make updates to existing, working, scripts that relies on the current way of working...

This is a screwed up way of cramming this down peoples throats..

This is not even a
"Sorry we broke it, but we did not think of this small use-case"
but a
"Hey, we think this is good so we are purposefully going break a shitload of stuff just because we think it's better way of doing it."

Re:I assumed this was already a default

[Anonymous Coward]

This could be interpreted as a joke for normal people, but for systemd people this would be a fully acceptable way..

Re:I assumed this was already a default

[Anonymous Coward]

Then go look at cgroups...

You are so short-sighted and only focused on *YOUR* use-cases and nobody elses. Changing behaviour like this is just crazy.

This basically breaks tons of commands i have on my system that have been written, and for them to work with systemd i will have to rewrite a shitload of scripts/commands for them to continue to work.

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

[Anonymous Coward]

Depends on what A,B,C,D,E are doing..
In some cases you have to restart A,B,C,D,E
In some cases you have to restart B,C,D,E
In some cases you have to restart C,D,E
In some cases you have to restart C,E
In some cases you have to restart just C
In some case you have to restart B,C
In some cases you have to notify process Q before or after relaunching C
In some cases you have to have to run Z once before restarting C
and so on... In a few cases you may even have to reboot or re-plug some hardware.

It all depends on the applications running, and controlling all types of dependencies there is should then not be up to the init-system.
A service that could provide this could be written completely standalone from systemd and executed from standard init-scripts..
One dependency-tree for your networking-management with custom actions/events executed before/after different tasks
One dependency-tree for your X system with custom actions/events executed before/after different tasks
One dependency-tree for your printer-setup with custom actions/events executed before/after different tasks
etc.

systemd has tried to solve some limited things, and done it it a fairly intrusive way, and causing loads of existing, and working, things to break. And all the systemd team has replied when people has complained is basically "fix it on your side, this is how it works now.".

I would not mind systemd if it would be split up into smaller chunks where each distribution could choose to use the parts that are good for them instead of making it this huge monolithic monster that just gobbles up everything.

Re: I assumed this was already a default

[Anonymous Coward]

Better for your use-cases perhaps.. Breaking tons of existing scripts/commands for others.

Re: I assumed this was already a default

[Anonymous Coward]

Dad's been balling your girlfriend upstairs, when you're not home, for four and a half years. Maybe you're the one who should GTFO.

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

[Anonymous Coward]

systemd is considered part of userland, and so it's largely not relevant to kernel dev at all (aside from the mantra "never break userspace"). Linus didn't have a problem with all the systemd bullshit until they tried pushing kdbus into the kernel, and the time systemd broke because it did the wrong thing with a kernel boot flag and they had the gall to tell the LKML to fix *their* problem.

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

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

[segedunum]

.....and OS X also implement nohup properly ;-).

Re:I assumed this was already a default

[Anonymous Coward]

C'mon - what the hell is this shit? OMG - REALLY? Wow - there it is. Crazy.

Somebody needs to get Pottering a girlfriend or whatever. He's going nuts.

By now this has become a job for a squirrel. Or both.

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

[Anonymous Coward]

Why do you imagine there are no drawbacks? There are solid reasons not to change the default, such as the principle of least surprise. Also the change breaks userspace, which is something you shouldn't do.

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

[Anonymous Coward]

Yup, in over 10+ years of supporting various systems handling 1/2 million users I've never seen this kind of crap either. Nobody in their right mind would ever design a platform in a long linear single point of failure chain. systemd is a problem desperately searching for a solution.

Re:I assumed this was already a default

[Anonymous Coward]

Obligatory image

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

[Anonymous Coward]

The systemd team has a VERY good reason for the change: to assimilate and control.

Re:I assumed this was already a default

[Anonymous Coward]

because systemd is not logic, it is RELIGION.

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.

Re:I assumed this was already a default

[Anonymous Coward]

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

They already have one, the problem is you all ended up creating a dependency on it. This demonstrated that in a large part the Linux community is dictated by RedHat, hopefully you have learned your lesson and wont be so stupid this time, trading control for short term gains.

Re:I assumed this was already a default

[Anonymous Coward]

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

And what effort did you make in contributing to an alternative? Red Hat is a corporation, they do what is best to serve their corporate interests and shareholders. The downstream projects that stand on its shoulders arent Red Hat's concern. You could fork their project, you could patch their version or you could switch your upstream to a different distro that doesn't use systemd like Slackware or Gentoo. So stop being such an entitlist and understand that these people do not work for you.

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

[Anonymous Coward]

Gnome having bugs they don't want to fix

It's open source! Fix it yourself or fund a bug bounty. This is the problem with open source these days, all its users are like you and believe they are entitled to have software produced that does exactly what they want for no effort. If you don't like it then use an old version, fork and maintain a pre-systemd version, use a distro that doesn't have systemd, patch the existing distro with a new init system or fund these tasks if you don't have the ability to do them yourself but stop thinking you are entitled to have other people do things for you.

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

[Anonymous Coward]

If you are backgrounding all the process, why even bother logging out?

If you're not logging out, why bother backgrounding the process? Many, many times, you need to run a long process and you can't be assured of your connection staying up. Using screen or just nohuping and checking the results later is a perfectly valid use of computing resources (and one I perform more than once daily).

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.

Well fuck you, systemd

[Anonymous Coward]

This might just be the final straw that gets me to move over to one of the BSD Unixes. I ran OpenBSD a few years back and it was a solid OS, may have to load it back up on my beater machine and give it another whirl.

Re:Well fuck you, systemd

[Lumpy]

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

Re: Well fuck you, systemd

[Anonymous Coward]

So you want some roughe process survive when you log out from BSD? I don't tjink that the BSD devs agree with you though.

Re: Well fuck you, systemd

[Anonymous Coward]

What processes did you want to keep running exactly?

This change affects barely anyone honestly.

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.

Re:Well fuck you, systemd

[whoever57]

Or Gentoo. systemd is optional on Gentoo.

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:Well fuck you, systemd

[Anonymous Coward]

Depends on your definition of a "ill behaving process". If I login into a BSD box to create a database dump, I'm not expecting it to kill the process just because my internet connection failed. That's why programs like screen and tmux exist.

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: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:Well fuck you, systemd

[Anonymous Coward]

Long-running processes are frequently desired behaviour though. It's fairly common to run a daemon as a user during development work or leave a program compiling while you move onto other tasks. Your session is the interface to control the other machine in a multi-user setup and not necessarily your entire usage of that machine. The program running in the foreground ill be killed when ssh detects you're disconnected unless it's designed to do otherwise, anything put into the background and modified to survive a tty disconnect has been put there for a reason.

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

From a security perspective...

[Anonymous Coward]

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?

Re:From a security perspective...

[jedidiah]

You morons all sound like a bunch of Mac users. Something from upstream does something unexpected and stupid and you idiots start making up excuses for it. It's violating expectations that have existed from the dawn of Unix quite possibly since you were even born.

You are confused.

This is Unix, not MS-DOS.

Re:From a security perspective...

[Anonymous Coward]

Sure, and you should install every package in the distro because, it is Unix
And, don't bother with strong passwords... because it's Unix
and... dump sudo (and logging) because it's Unix (and you like being root)...
Eff the most recent patches, and ignore SANS for the bunch of twats they are... because Unix... right?

Just throw away every security convention, because it is pussy-willow behavior, not worthy of Unix

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

[SumDog]

It's not a bloody small change in syntax. It's a fundamental design change on the way linux processes and logins work. This breaks a lot of stuff and should have a massive red warning on it. It should be a major release and not an incremental change (if it were even a good idea, which it's not).

Re:From a security perspective...

[Anonymous Coward]

systemd was created by a bunch of gamers who get their panties in a bunch when some background process or daemon is consuming CPU cycles that could be used for rendering 3D bimbos. Everyone else can just go fuck themselves.

Re: From a security perspective...

[Anonymous Coward]

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

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

[Anonymous Coward]

Or you could stop being an asshat and cease characterizing legitimate complaints as "hissy fits".

Then you can go fuck yourself with a rusty chainsaw.

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

[Peter H.S.]

It's not a bloody small change in syntax. It's a fundamental design change on the way linux processes and logins work. This breaks a lot of stuff and should have a massive red warning on it. It should be a major release and not an incremental change (if it were even a good idea, which it's not).

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. This is conceptually very similar to how things always have worked, It is simply the way to explicitly tell the system a process is allowed to survive that have 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?

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.

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

[Peter H.S.]

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.

Re:From a security perspective...

[Anonymous Coward]

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

Except that has never been the meaning of logout on UNIX. Log out means "I am no longer using this terminal", and the UNIX kernel even jumps through hoops to track session leaders and process group leaders, and cuts off access to the tty when the session leader exits. Several Unices have this behavior already as a non-default option, but it's only really useful on shell and demo servers, because everywhere else, it's NORMAL for users to login, establish some jobs, logout, and come back when they're done.

Re:From a security perspective...

[Anonymous Coward]

If that new command encompasses all the functionality of nohup, then yes should only have become the default after nohup was updated to be a wrapper of that new command, and all other traditional functions updated also to use the persistence system "properly".

Since systemd doesn't control the owners of those other programs, they should have worked with the Unix community to propose and vet the new behavior before switching to it unilaterally.

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

[Anonymous Coward]

Yes, a slight change on a perfectly working convention because of a bug in another piece of software. As usual with systemd; and the "another piece of software" is GNOME as usual.

Re:From a security perspective...

[Anonymous Coward]

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?

So please name me just one example of technical rationale that this change is based on, that is not a bug in some other software? What you said is nothing but "we did it not because it's good, but because we can".

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.

Didn't systemd already do this automatically? And these benefits (in case someone really wants) are not even related to killing background processes.

Re:From a security perspective...

[Anonymous Coward]

Something from upstream does something unexpected and stupid and you idiots start making up excuses for it.

For fuck sake any of the projects consuming systemd, any of the upstream distros your distro is derived from, your distro or indeed you yourself can make this change instead of trying to dictate what other people do in their project that you consume. If nobody else did it then remember not to just blindly swallow everying upstream gives and change "yes" to "no" in the config file as indicated.

Whining about it will get you nowhere, but of course people like you have continuously failed to learn this since systemd began.

Re:From a security perspective...

[Anonymous Coward]

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

Which, if really wanted, could already be easily done long before existence of systemd. Just a cron job to kill process of logged-out users.
So you actually admitted that systemd deliberately broke another convention for not a single technical reason? ;)

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

[Anonymous Coward]

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. This is conceptually very similar to how things always have worked, It is simply the way to explicitly tell the system a process is allowed to survive that have changed.

I think you're misunderstanding the rant. The rant isn't so much "systemd is changing the default." That's not what most others (including myself) are ranting about. 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."

The fact that systemd set its default to an even sillier behavior is one more bit of evidence that systemd should be completely scrapped. Every system I've encountered with it has left me frustrated to the point of nuking that system and putting FreeBSD or CentOS 6 on it. So far I've encountered two CentOS 7 servers that I upgraded to v6 recently.

Re:From a security perspective...

[Peter H.S.]

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

Just edit your scripts. You had to edit them too when ssh replaced rsh back in day. Or just set "KillUserProcesses" to "no" and live with the same old problems. Hardly a big deal.

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

[Anonymous Coward]

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

The answer is that you allowed it. RedHat made no secret of the fact that they were going to use systemd, at which point you should have said 'ok we dont like this direction and will fork', that is how open source works. You created a dependency on RedHat and then when they decided to do something you didn't like you did nothing but whine about it. RedHat isn't beholden to your whims and if you're going to capitulate no matter what they do then you deserve whatever you get.

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

[Anonymous Coward]

If it kills screen sessions, its basically unusable for me (even if it is a configurable default)

Re:From a security perspective...

[Anonymous Coward]

"The old problems" could already be solved with a simple cron job, so "hardly a big deal"; that systemd breaking lots of old configurations by default is a big deal. If you break things for almost no good, you shall fix it.

Re:From a security perspective...

[Anonymous Coward]

No. "You caused the problem, you need to fix it", whether open source or not.

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?

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

[Anonymous Coward]

Do you really think this is going to happen?
This will break lots of software, there is a lot of badly written software out there wish uses screen on startup.
Do you really think that these scripts will be changed ? They will change the default especially since there are no security implications on most server setups.

Re:From a security perspective...

[Anonymous Coward]

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.

He's right, though. You are an idiot.

Re:From a security perspective...

[Peter H.S.]

Just edit your scripts.

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

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

But I don't care whether you edit your scripts or not. If you prefer prefer broken scripts to editing them, that is your problem, not mine.

Re:From a security perspective...

[Anonymous Coward]

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

But I don't care whether you edit your scripts or not. If you prefer prefer broken scripts to editing them, that is your problem, not mine.

Except that it's your so-called "new tech" (which is a lie; killing logged-out users' background processes has long been trivial), not the scripts that are broken :D

Re: From a security perspective...

[Anonymous Coward]

It is a valid technical argument, breaking expected behavior of software is a real problem. This change will create a lot of headaches and extra work for sysadmins while there aren't any really benefits in most use cases. Especially if you didn't see this coming. This will create a lot of problems for smaller companies who might not have the most competent sysadmins.
Personally I will do what I do to all defaults. Have puppet set them to the value which is best for our use cases.

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

[Anonymous Coward]

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

Thank you. I *finally* understand where the hell the systemd people are coming from. They have to destroy Linux... in order to save it!

Re: From a security perspective...

[Anonymous Coward]

WTF

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

[Anonymous Coward]

that's most certainly so. According to his profile on /. foes already outnumber friends by a factor of 6. Wow.

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

[Anonymous Coward]

It's not a problem. I'll troll him back as soon as he takes a break from fellating Lennart.

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.

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

[Anonymous Coward]

A lot of developers and sysadmins use Macs too. There's one here who wouldn't make up excuses for systemd. Get rid of it.

Re:From a security perspective...

[Anonymous Coward]

it is yet another change where systemd changes things
and those changes require the rest of the world to adapt to systemd

this is what people mean when they say that systemd is tightly coupled
and this is why people get upset

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

[Anonymous Coward]

So you means, you need users to know about the existence and syntax of systemd commands to be able to properly run thinks like screen or nohup.

Oh, when you are under a systemd linux, so you need to add the trivial "systemd-run --user -scope" in front of your nohup invocation. I know it breaks your existing scripts, that launch those huge computations on the cluster, but it is better that way. /s

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

[Anonymous Coward]

But please.
Don't use systemd then! sysvinit, initng (and 3 or so other init alternatives whose names I have forgotten) did not disappear. Read up on them, use the one that fits your use case best. And if it isn't perfect - contribute a fix or write an init that is perfect for your use.

Cooperating with others who don't like systemd may be necessary to actually beat systemd now - but either way, you don't have to use systemd.

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

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

[Anonymous Coward]

So, now I first have to figure out if the system I am logged into is a normal Unix system or uses systemd with a braindead config?
In a few years, I will probably need to download a big shell script or even run an autoconfig script to know if I can just type nohup or need to do some secret ritual to get long established normal behavior?

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

[segedunum]

Not a convincing argument I'm afraid.

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?

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

[Anonymous Coward]

No. "You caused the problem, you need to fix it", whether open source or not.

Correct, you created a dependency on RedHat and now they are doing something you do not like. They are not beholden to your whim, they can do whatever they wish with their project. You were stupid and now you have to fix your mistake.

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.

Debian

[Anonymous Coward]

Looks more like a Debian thing. It's the Debian maintainers who decides what the default value of configurations should be.

For desktops however this sounds like expected behaviour which is nice to finally have.

Not a fan

[Anonymous Coward]

Michael Biebl seems incredibly arrogant at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=825394#40

and clueless at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=825394#45

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

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.

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

[F.Ultra]

Link to where Poettering says that. The guy doing strange replies in the Debian bugtracker linked in TFA is some one else (Michael Biebl). It also looks like setting this variable in logind.conf to "no" disables this behaviour. Agreed that this is indeed a bad default it it really gets to be the default value on servers but if so then it's Debians fault because they are the ones who control the default values in their distribution.

Re:WTF

[Anonymous Coward]

Fuck you and fuck systemd. I hope Lennart dies choking on your dick.

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

[BlackPignouf]

You're totally right he didn't call anyone a moron on this issue, *yet*.

Re:WTF

[Anonymous Coward]

which does bring the systemd developer's competence into question

I don't follow systemd development. Was the "developer's" accidental, or is there really just one main developer of systemd?

Re:WTF

[AmiMoJo]

My mistake, should be developers'.

Re:WTF

[sjames]

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

Re:WTF

[Peter H.S.]

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.

"screen" will work exactly as it always have, even with the new defaults. 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.

All programs started from "screen" will run in this scope and will therefore remain after logout too.

Use "systemd-cgls" to get an overview of where the new scope is attached.

The man-page is good to read if you want to understand how things work : https://www.freedesktop.org/so...

In short, don't go on hearsay but read the technical documentation.

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

[Peter H.S.]

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

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]

Except that isn't how it's always worked. Thata how it's never worked, and why the rest of us wish people like yourself would stop fellating Poettering.

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

[Peter H.S.]

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.

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

[RightwingNutjob]

All the more reason not to blindly run updates every time they come out "because security." In what reasonable world is some kid in underpants in his mother's basement have root on your box, just because they're "the dev team."

Re:WTF

[Anonymous Coward]

"Binary logging is just part of tech. Get used to it."

"Having Windows 10 shoved down your throat is just part of tech. Get used to it."

Yeah, nah.

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

[Peter H.S.]

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!

The way you run the programs may have changed, but not the functionality. Screen works just like expected when started by systemd-run once it is running. So no functionality is lost.

Being able to run stuff in the background has been around for decades

This isn't about running stuff in the background (though systemd-run can do that too), but about keeping processes alive after logout.

With systemd-run the programs get their own scope that you can manipulate with standard systemd tools and use many of the standard systemd resource management features like limiting IO etc. In short, you can trivially constrain your long running processes so they don't DoS the system, even if some process went rogue.
Another major benefit is the ability to safely purge the user session in a clean way, so that only explicitly allowed processes survive the logout.

Anyway, it is trivially easy for those who want it to revert to the old (rather hackish) way of doing things. man logind.conf will show you how.

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

[RightwingNutjob]

Just get ready for the next round of complaints to be met with blythe assertions that you should implant a systemd chip in the back your head...so your brain won't make your fingers type out complaints about systemd.

All glory to the systemd...clap...clap...clap

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

[Anonymous Coward]

which does bring the systemd developer's competence into question.

The competence of the systemd has never been in question - they are extremely (and may I repeat extremely) incompetent. This just offers further proof.

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

[Anonymous Coward]

No, the new default is best practice in *some* cases. I don't need gvfs hanging around, or 37 instances of gnome-keyring, but I would like my xpra session hanging around. I don't want to discover at oh-dark-thirty that because I rolled out some security updates, web applications that "always just worked" are suddenly dying because some swaggering, overbearing, tin-plated dictator with delusions of godhood decided to rewrite the standards of what processes are killed and what processes aren't killed when I logged out.

Whether that's Poettering or some debian package maintainer, I don't care. I want them hunted down, and beaten severely with the Nerf Bat of Behavioral Conditioning.

And if I didn't start the process with systemd, I damned well don't expect systemd to kill it for me to be "helpful". That's not helpful, that's draconian.

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

[Anonymous Coward]

I'd also add that he appears to be an ass.

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

[Anonymous Coward]

Poettering is an idiot and that's that. It's his level, not mine.

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

[Anonymous Coward]

and your post is the single most obvious proof in this universe that you have the intelligence or rather lack thereof of a duck swimming in its own pool of pi** and thinking its the ocean.

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

[Anonymous Coward]

But you should "just" make a systemd script for running the things in background and reboot your machine when you leave. Or perhaps they solve this by a screend, which implements half of the current screen's features and event them in completely opposite logic. The screend may also have some nice dependency on gnome3 and NetworkManager to get some cross promotion.

Re:WTF

[Anonymous Coward]

he is offering an API for it.

Jesus, how much software is going to have to be modified to accommodate a fucking init system? This is ridiculous.

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

[AmiMoJo]

Killing processes is the correct solution.

Every process somehow needs to know when the user logs out, and some will want other useful information like when the machine is going to sleep or is idle. There are a number of ways to do it, all incompatible and badly supported by numerous #ifdefs.

There are only two ways to resolve this.

1. Create a new API and demand everyone uses it. systemd has been criticised for this in the past, and previous attempts by others have just fragmented the ecosystem even more. It also relies on each process behaving well, and maintaining them all if something needs to change in the future.

2. Send shutdown signals to processes when the user logs out. Have a whitelist of things you don't want to kill, which will be quite small. Only the login manager needs to change.

All they need to do is add a better way to set up the whitelist.

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

[Anonymous Coward]

telnet isn't installed by default on Debian, think it was that way since lenny. netcat is installed by default though, but old fashioned as I am I stick to telnet (and thus my custom user package depends on it).

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

[Anonymous Coward]

So, this invocation of screen is the more secure, right? Because that is what prompts the change, better security, right? Bad guys won't be able to use that line somehow, correct?

Re:WTF

[Anonymous Coward]

It certainly worked against Nokia, it both killed the business and let them get their vile pseudopods on all those mobile patents. I'd say the likelihood is disturbingly high.

What angers me is that it's become apparent that the Linux ecosystem is now entirely dominated and controlled by corporate concerns. The individuals that were a part of the system and have contributed to the success of Linux have been completed disenfranchised and are now treated like little more than consumer cattle.

I'm surprised there has been no rallying call to take back what was ours; instead I'm debating fleeing to BSD land, where freedom is still intact, and taking my technical skill and work with me.

Re:WTF

[Anonymous Coward]

Fedora 23 doesn't have that version of systemd yet - this change appears in version 230 and F23 has version 222 right now.

There's also currently a discussion on the "devel" Fedora mailing list about it, and most people are calling for that to be turned into a "system-wide change" for F25. That would mean that the Fedora Engineering Steering Commitee (FESCo) would have to properly discuss this and determine whether or not this change should be accepted (the default can be turned off at compile time). Someone suggested having it on for the Workstation variant and off for the Server variant.

https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/ZNQW72UP36UAFMX53HPFFQTWTQDZVJ3M/

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

[Anonymous Coward]

You have no fucking clue how professional system administration works.

TL;DR: You have no fucking clue how professional system administration works.

Captcha: quality

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

[Anonymous Coward]

You could make the same argument for god damned memory protection. Oh, shit's just masking software bugs. If every piss ant program can't shit all over the memory and crash the machine you won't know it tried.

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

[Anonymous Coward]

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

What a moron. User code don't stay around after the terminal is killed by default. You have to nohup for that.

Re:WTF

[Anonymous Coward]

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.

I feel like making a Martin Niemöller-like poem for systemd. We can now add "when systemd came for nohup" to the long list of shit that slowly got individuals to take notice of this nightmare of an OS that is systemd.

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

[Anonymous Coward]

According to TFA apparently lots of desktop environments do the "wrong" thing now than logging out no longer kills X and leave lots of processes running after the user logs out. This new default behavior in systemd fixes that.

Re:WTF

[Anonymous Coward]

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

So, what, you've never seen a change that you disagreed with?
Everything must be hunky-dory with you because you must bloody-mindedly equate change with progress.
Your opinion is worthless.

Re:WTF

[Anonymous Coward]

Depends on how you define "logged in".

Once you hit ctr+a d in screen, the screen process and the shell process it spawned (and anything you are running on it) will be found under init in the process tree.

If you log directly into a tty, the shell and children will live under login.

Similarly, ssh in and you will find the shell under sshd.

*nix do not really have a singular notion of what it means to be logged in.

Re:WTF

[Anonymous Coward]

& just runs the process in the background, nohup is what keeps it around after the shell exits.

Re:WTF

[Anonymous Coward]

Fedora developers, singing his emails with "Red Hat". I guess we all know where the buck really stops.

RH freaked when Oracle forked RHEL after so many years of fruitful partnership, and now they are trying to turn Linux into their own fief by building a second ecosystem on top of the kernel that RH controls the direction of.

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

[Anonymous Coward]

my default assumption is that everything touched by Lennard Poettering is poisened for he is an idiot.

Re:WTF

[Anonymous Coward]

Poettering said nothing of the sort, you just assumed he did as kind of reflexive ad-hominem.

It's like misattributing to Hitler something Goebbels said.

Re:WTF

[Anonymous Coward]

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.

Not even that. You need to detach from the controlling terminal, and & alone will not do that. So normal background processes will be killed on logout. Only detached processes (like those started with nohup) will run on. The systemd nuttery would have more of a point if you were correct.

Re:WTF

[Anonymous Coward]

This is yet another example of violation of the Principle of Least Surprise on the part of the systemd team.

Surprised?

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

[Anonymous Coward]

No one is emo-raging against Canonical like this for Upstart. Between my Ubuntu, Kubuntu, and Kali (Fedora) machines, there is a lot of differences in a whole lot of things. I'm constantly going to reference material for correct version specific command information. That doesn't even touch version to version difference of the same flavor of Linux. This is simply a narrowly and inconsistently applied argument against a favorite enemy for convenience.

Re:WTF

[Anonymous Coward]

I'm pretty sure systemd is more than capable of telling you what it killed as well. It's only silent if you don't care.

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

[Anonymous Coward]

He's... not even wrong. It's rather impressive, the number of misconceptions and sheer volume of ignorance he manages to cram into just six short paragraphs.

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

Except that it wasn't by default. You logout, your shell gets the HUP signal. That signal gets propagated down to all of the shell's children, and all of their children, and their children - all the way down to the end of the chain. By default, HUP terminates a given process. If it doesn't terminate a process as described, it's because one of three things has happened. First possibility: the process has deliberately severed its child-parent relationship with the shell, as any program designed to run as a daemon will do. Second possibility: the process has explicitly set a signal handler to trap (or ignore) the HUP signal. Third possibility: the process has been launched with the nohup command (which effectively is the same as the second possibility).

If a program hangs around after logout that isn't supposed to, that's a bug in the program, not in the operating system. The defaults are all set up properly; if a program deliberately sets out to ignore them, presumably that's for a good reason.

It has never been the default that a program will just hang around forever for no good reason.

we should consider it our duty as Fedora developers to improve the Linux platform

Right. That's it. I'm done. I'm out. I've been involved with Linux in some form or another since the days of the a.out to ELF transition - over ten years. I've been grumbling about systemd breaking a whole bunch of conventions for no good reason since I first laid eyes on it. This? This is the straw that broke the camel's back. Any operating system that quietly introduces a breaking change like this - something that is a fundamental part of the design of the Unix operating system, that is a basic assumption that every long-term Unix user is aware of - is not an operating system I want to have to deal with. Sure, it's easy to change the configuration setting for this thing. What about the next change that breaks something fundamental? Or the one after that? Or the one after that?

This isn't good enough. Sure, sometimes change is necessary - the a.out to ELF transition was done for good reasons; swapping out telnet to ssh was done for good reasons - but this kind of subtle breakage is a huge time sink to any halfway serious systems administrator.

Well, at least there are alternatives out there.

Re:WTF

[Anonymous Coward]

>We've used them for decades. There is no "problem" here. There's nothing to "solve" or "fix".

Exactly. Perfect description of how systemd, inflicted on those of us who have known what we're doing for decades by arrogant jerks who believe they know everything, is a solution in search of a problem.

Re:WTF

[Anonymous Coward]

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

OK, that's enough.

Fuck you. I have been adapting to changes in hw and sw technology since 1981. It is my job. Do not tell me I am "ejecting myself out of tech" through my failure to adapt (that is, acquiesce in Potterings ego problems) to a buggy, silently-failing, bug-covering daemon I never asked for and which radically changes (without warning) accepted norms of app behavior and otherwise greatly complicates my life (script revision, etc.).

Better is good, but it actually has to BE BETTER. OK?

Do not just toss out "old ways" just because you think you're smarter than all the old hands; do not dismiss decades of hard-earned knowledge out of hand because you don't understand it. Do not solve problems THAT DO NOT EXIST with sw that does not work as advertised.

If you cannot tell why your attitude is toxic, please go rent a clue.

And an the way to said clue rental, fuck yourself you arrogant, ignorant piece of shit.

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:WTF

[Anonymous Coward]

Case in point, you are a fucking moron if you believe the way things behaved in the past was the proper way.
Welcome to the 21st century! Please stay away from any remotely sensitive infrastructure!

misleading title as usual

[Anonymous Coward]

So they do what everyone else has always done which is extremely sensible in multi-user environments, and because of that they get a deceiving headline on ever-decreasing-quality slashdot. If I want to read untrue clickbait I'll read yahoo.

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

[Bing Tsher E]

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.

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

[Anonymous Coward]

I don't see "rewrite everything in the past" as being hyperbolic.

I'm at a crossroads. I have some old Debian systems that I'm planning to upgrade. They run a number of shell scripts, some of them dating back many years. So now I'm going to have to audit all of these existing shell scripts, many of which have worked just fine for over a decade, and insert "systemd-run --user --scope `program` " where necessary.

Well, if I have to audit all of my scripts, and potentially modify them, I might as well just do it as part of a move to FreeBSD. At least in that case I'm doing the audit for the right reason: I'm moving to a better operating system that won't surprise me with nonsense like this. Plus I won't have to insert all of these goddamn systemd-specific calls all over the place.

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

[Anonymous Coward]

How's this for a tech argument, you sack of idiotic shit.

1. systemd is a (shitty) init system. It is *not* a shell nor is it an OS.
2. One's init system should not leverage special magic syntax onto one to get expected behavior from programs that have been around for more years than your IQ.
3. Principle of Least Astonishment is a very real thing. I'm sorry your feeble brain can't fucking grasp it.
4. Go back to sucking Pot's dick; no one really wants to hear you speak anyway.
5. Take your magic syntax that no one wants to have to run and fuck yourself with it. Goddamn fucking shill.

Re: misleading title as usual

[Barsteward]

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

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.

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.

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

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.

Oh no!

[fph il quozientatore]

Oh no! We've always done it this way!

Re:Oh no!

[Anonymous Coward]

that is an appropriate response when the proposed solution is for a problem that does not exist or causes more problems than it solves.

Better is only good IF IT IS BETTER.

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

[Anonymous Coward]

I bet you'd be fun at parties if anyone actually fucking invited you to them. Oh sorry, "fsck," fuck is a word that you're obviously unfamiliar with on any level.

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

[Anonymous Coward]

> The old init systems are creaking under the weight of many patches, scripts and hacks.

FFS.

Have you even heard of OpenRC? s6? daemontools? runit? There's a whole _world_ of sysvrc/sysvinit replacements out there that aren't a steaming pile of accreted copypasta. Go see what vezzy_fnord has to say on the topic on Hacker News. In one of his posts, he gives a really good reading list for interested parties. Sadly, I cannot remember which post, but some clever searching will lead you to it.

Re:To be quite honest...

[Peter H.S.]

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.

You are of course wrong. Probably because you never read the technical documentation on this but just relied on wrong hearsay.

Here is the relevant man-page:
https://www.freedesktop.org/so...

As you can see, even with the new defaults, it is trivial to make GNU screen or tmux keep running, even after logout, even with the new defaults settings. You just start them with "systemd-run --user --scope screen" and everything works as before (just a little better).

Re:To be quite honest...

[fnj]

The old init systems are creaking under the weight of many patches, scripts and hacks

Bull. I stopped reading right there.

Re:To be quite honest...

[Anonymous Coward]

Indeed.

Meanwhile, Amazon's default Linux image on EC2 is still systemd free, and seems to be doing just fine.

I think the time has come for a "Desktop" fork and a "Server" fork.

Because a desktop user has different needs and expectations than a server admin.

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

[Anonymous Coward]

...creaking under the weight of many patches...

That is not how patches work. Patches are the result of new functionality or bugs or edge cases getting corrected. When you do a re-write, you lose all of the lessons you learned the first time around and get to make them all over again. By the time you re-stamp-out all the bugs you re-introduced, you'll often find that your new system is even equally a "collection of patches."

Re:To be quite honest...

[Anonymous Coward]

How about I just run 'screen' with no extra command line arguments, with no aliases, and Pottering et al. stop fucking with the UNIX workstation which has worked just fine as-is for decades.

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

[Anonymous Coward]

I can tell you suck at programming. Doing cleanups, aka refactoring, shouldn't create bugs. Patches shouldn't degrade software quality. The GP was spot on, except you shouldn't forget what you learned when you attempt a re-write.

Re:To be quite honest...

[Peter H.S.]

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.

Just recall the command line from the stack. No need to type when eg. "Ctrl-r" works so well.

Really such changes occur all the time in tech; we no longer use telnet, rlogin, uucp and similar old and insecure stuff anymore either. It must be hard to work in tech when unable to learn new commands and new ways of doing things.

Re:To be quite honest...

[Anonymous Coward]

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.

Both my BSD and Linux boxes use init scripts (I hate dealing with systemd). What problems am I having that I need them replaced? First of all who even reboots machine often enough that init scripts even matter that much. I can't say in 20+ years of using UNIX that init scripts were the thing that frustrated me (at all).

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]

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

No, only for clueless morons like yourself.

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

[Anonymous Coward]

Well openrc seems to work decently.

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

[Anonymous Coward]

You do know you come off as a dick. And you probably are. Yes, nothing to do with the current discussion, just pointing out the obvious.

Re:To be quite honest...

[Anonymous Coward]

In what way was "screen" insecure before?

"It must me hard to work in tech [without learning new stuff]": If I'm going to learn new things, I want them to gain me new functionality. This gains me NOTHING. My processes exited when I logged out on every Unix system I've ever used. Maybe Gnome has issues, but I don't use it. Now, suddenly, to solve problems in a a Window manager which *I don't use*, I need to learn a new, and significantly longer, command line in order to run screen. Or nohup. Or any number of other things. And once I remember that command (and no, I can't just "recall it from the stack" when I'm on a new machine that I haven't typed it on before, and yes, that is something that occurs constantly) I get NOTHING else. When I learned ssh to switch away from telnet/rlogin, I got all kinds of new functionality as well - encryption, port forwarding, SOCKS proxy, secure password-less login, etc. When people (I'm not quite old enough) switched from uucp to ftp, they got new functionality - instant transfers, ability to list files on the remote end, etc. What is it that my computer is going to do better because this feature has gone into systemd that makes it worth my time to learn it?

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

[Anonymous Coward]

Just because you don't know of or realize that there are modern alternatives to systemd, that doesn't mean they don't exist. OpenRC is just one of them.

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

[Anonymous Coward]

In case the change of the default would have been preceeded by patches to screen, nohup [,...] to keep the prior, expected behavior this might have been acceptable.

As-is this needlessly breaks userland existing for decades.

With the stance of 'just prefix the command' you completely ignore that this creates massive amounts of work for admins since they have to revisit every place such things might have been used, senseless wasting lifetime of real people.

Behavior like that doesn't make me wonder why some people want to see the ones responsible for systemd die in a fire...

Re:To be quite honest...

[AmiMoJo]

It seems like systemd succeeded in being faster and easier to manage. Instead of having many scripts scattered in different places and written in different languages, often relying on custom command line parameters for each program, it offers a consistent interface to manage everything. And it definitely does boot faster in my experience, so the speed claim seems valid.

I'm not saying there aren't things to dislike about it, but I'd much rather be dealing with systemd than having to administer multiple machines that are held together by the equivalent of duct tape.

Re:To be quite honest...

[Barsteward]

RTFM before you jump

Re:To be quite honest...

[Anonymous Coward]

... it is trivial ... You just start them with "systemd-run --user --scope screen" and everything works as before (just a little better).

I'll give you the benefits of the doubt and assume that this was one huge beautiful sarcasm.

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

[Anonymous Coward]

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.

And if SystemD had stopped there, at replacing that thing that the majority thought needed replacing, and did it well, a lot of people wouldn't have such a problem with it.

Re:To be quite honest...

[Anonymous Coward]

You just start them with "systemd-run --user --scope screen" and everything works as before (just a little better).

I like 'nohup' better. It is shorter, and feels more 'unixy'.
Also, I remember it more easily, as I've been using it for decades already.

Now, why was this new version better?

Re:To be quite honest...

[Anonymous Coward]

Why keep track to shutdown things? Why not use the systemd approach and just kill everything still running before un/re mounting the filesystems?

But the old way is to just call all stop scripts of services installed, the worst thing is that a service isn't running (which is usually checked with pid files).

Re:To be quite honest...

[Anonymous Coward]

The only problem I ever encountered was that mounting nfs shares failed due to some out of order processing in debian with etch or maybe even lenny on very specific machines. You had to babysit reboots or wait for the monitoring system to tell you a server was down.

Re:To be quite honest...

[Anonymous Coward]

The only way to combat systemd is to build something better. Fork it, or just start from scratch.

We can no longer fork it, systemd will just kill the resulting process at logout.

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

[Anonymous Coward]

Seriously, now, fsck systemd

You should not use fsck with systemd, only outdated filesystems rely on it and it does not fit the vision of systemd's creators. See the issue about broken interrupt handling for running fsck processes for more detail. Most likely you want to /dev/null systemd, at least while that is still supported.

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

[Anonymous Coward]

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.

What alternative is needed? I personally am fine with how (e.g.) Debian 7 did things. I saw no extra benefit from the SystemD way of doing things in Debian 8.

I've been doing sysadmin for over a decade, and running Linux since the a.out days (along with BSD and Solaris).

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

[Anonymous Coward]

"I don't want to fiddle with settings to get things to work right for me so I... will run OpenBSD?"

Please tell me you have enough self awareness to be a troll.

Re:To be quite honest...

[Anonymous Coward]

So, one has to jump through extra hoops, just to get normal behavior?
I consider tmux, screen or nohup (especially NO HUP) not to hang up normal behavior.
Looking for man pages of yet another broken init system which is probably replaced soon by the next shiny new thing is not trivial.

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

[Anonymous Coward]

Never heard of OpenRC? Supports cgroups, familiar bash scripting (and a set of functions you can import to make things a bit nicer to write daemons for), and it may even support systemd unit files in the future, rendering it the best of both worlds.

Re:To be quite honest...

[Anonymous Coward]

Po[e]terring's insights

And what exactly are those? systemd was inspired by SMF and launchd. It does absolutely nothing innovative and new. OpenRC and runit can both use cgroups. Socket activation can go either way but is usually a bad idea. Honestly Poettering's not brought a single *good*, *new* thing to GNU/Linux. PulseAudio was basically copying how Windows handled audio, and it didn't approach anything remotely stable until someone else took up the project. The same goes for avahi, zeroconf, consolekit, and other projects he's ruined and later absorbed with systemd.

I forget who said it, but it was a law claiming that all programs will increase in complexity until they can send e-mail. Wonder how far off systemd is from that. Maybe it'll absorb postfix! (I hope not...)

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

[Anonymous Coward]

wasting time learning new broken ways to do old unbroken things isn't daunting, it's a stupid useless time-wasting pain in the ass for those of us in the real world with real jobs that rely on software that really works as we expect it to; cf "The Principle of Least Surprise".

Re:To be quite honest...

[Anonymous Coward]

To be fair, it was more like

$ nohup cmd &

But the point is well made.

Windows 10 or systemd

[negrace]

Pick your poison

Re:Windows 10 or systemd

[Anonymous Coward]

I myself prefer a fine glass of gentoo.

Fuck systemd

[Anonymous Coward]

#fucksystemd is all I need to say ever. I never ran so far away from a Linux distribution as when systemd started taking over everything. I had to abandon Fedora which I'd been using for almost 10 years at the point I realized it was killing my servers with its bullshit. Thanks to its horrible "integration" with syslog, I lost a lot of valuable log info when my site was under attack. Go ahead and mod this "Troll" if you don't understand how Unix/Linux has worked for all this time...

Here is a REALY BAD SCENARIO for systemd

[Anonymous Coward]

Let's say that I run a program that is "old", BUT I can't upgrade it to the "latest version"...because something else running on the server REQUIRES an older library (no...I can NOT use LD_LIBRARY_PATH)...what happens if I just - ON MY DISCRETION - want to go out and check for a new version of the software I use and download it - IF I WANT TO...

A "code/script" snippet...

#the lftp script will download if it sees a newer version of the software I want

nohup lftp -f get_my_stuff.script &

My script could only run a long time if newer stuff is available to me...

Does systemd have the "right" to kill my proc? HELL NO!!!

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.

Re:egotistic breakage charisma

[Anonymous Coward]

This story: Systemd Starts Killing Your Background Processes By Default

Previous story: Massive Backlash Building Over Windows 10 Upgrades

Story before that: NetBSD 7.0.1 Released

Just sayin'...

Re:egotistic breakage charisma

[Anonymous Coward]

If you are a BSD user then don't fucking comment.

Re:egotistic breakage charisma

[Anonymous Coward]

It's a little bit weird to see this all fall by the wayside while the actual work (ie. hardware) continues on in the convoluted stupid unknown universe it doesn't deserve. That is, oscilloscopes that suck not because of hardware but because of the shit software/firmware on them. The simple fact is, hardware engineers SUCK at software development yet they are the ones creating it all. In the worst way possible. Morons is too light of a term to describe these idiots.

Slashdot made this hell to reply to. I have done the captcha a dozen times correctly and it still won't let me post. WTF... Seriously, the overloads have won. Assholes!

Re:egotistic breakage charisma

[Anonymous Coward]

The problem with PC-BSD for me is that the interface still looks like it was designed by a 7-year old. Even the friggin' default background images seem like an experimentation in GIMP. Yah, KDE and whatnot, customize it as you see fit, but it either looks good or it doesn't. And PC-BSD doesn't. Almost every major linux desktop distribution provides a better user experience than PC-BSD (most of them still suck, but at least they don't look like something from the past century). And for me, this is sad - I've been a OpenBSD and FreeBSD user for many years, still am - and I'd love to replace my current desktop environment with a BSD system.

Re:egotistic breakage charisma

[Anonymous Coward]

What happens when the poetterings of the world go after BSD too?

They _will_ go after BSD.

Re:egotistic breakage charisma

[Anonymous Coward]

We can do better! Imagine systemd opening a dialog for upgrading to Windows 10. Two yes buttons, one of which is disguised as the red x in the corner.

Re:egotistic breakage charisma

[Anonymous Coward]

Why? Someone who uses a BSD may have more insight into their world and be able to tell us how things are going for them. Software diversity is part of why libre software is so awesome.

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?

Ung!

[Anonymous Coward]

"I believe this *is* it the expected thing to do on personal computers. "
Martin Pitt http://www.piware.de/

Can somebody please fire this guy, he clearly has no clue AND IS DESTROYING LINUX

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

[Anonymous Coward]

Sure, FreeBSD is great until those lazy fuckwits forget to test their shit and you are left without /lib when freebsd-update does it's thing like what happened at the 10.1 upgrade. At least Debian tests their upgrades.

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

[Anonymous Coward]

Except for the fact that Martin Pitt thinks it's a good idea (and he's both ubuntu and debian lead developer).

Re:A total non story ..

[Anonymous Coward]

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

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:

* https://www.freebsd.org/cgi/man.cgi?query=nohup&manpath=2.10+BSD
* https://svnweb.freebsd.org/base/head/usr.bin/nohup/nohup.c?view=log

screen and tmux are only recent incarnations of the idea.

Re:A total non story ..

[Anonymous Coward]

Why can't we just set LoadSystemD=no instead?

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

[Anonymous Coward]

Nope, because software will expect KillUserProcess to be yes, start ignoring SIGHUP, and stay alive in your configuration after logout.

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

[Anonymous Coward]

yeah right.

and what if you don't have root access.

Re:A total non story ..

[RightwingNutjob]

Is he also the lead user?

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

[Anonymous Coward]

because of faggots of course

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

[Anonymous Coward]

... but not unexpected.

Re:It's all Gnome's fault

[Anonymous Coward]

...poorly written stuff like PulseAudi...

Hahahaha! So Poettering is trying to clean up shit that his old project left behind.

Re:It's all Gnome's fault

[Anonymous Coward]

GNU's Not Unix! Network Object Model Environment is the official desktop environment of GNU's Not Unix!/Linux

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

[Anonymous Coward]

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

No. This issue in isolation doesn't warrant the backlash. The problem is that it isn't just this little issue.
People are starting to notice a trend where multiple issues they encounter appears to have the same source.

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

[Anonymous Coward]

Hmmmm PulseAudio.... I wonder who's behind that awesome piece of software.... AHMAHGAWD Poettering!

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

[Anonymous Coward]

but the sheer amount of hateful bile being spewed is absolutely not warranted

If this was an isolated issue you would be right, however the people behind systemd have time and time again shown to break working code for inane reasons.

For example systemd does not forward interrupts ( Ctrl+C ) to fsck when run on startup, the official reasoning behind this consists of 3 rather questionable statements a) the lie that interrupting fsck is unsafe, b) a patronising comment how using older file systems is a bad idea anyway and c) a blurb about the vision of systemd. Point a) alone can only hold up if the person making the statement has no idea how Linux signals work and has never read the manpage of fsck, point b) is breaking backwards compatibility for the sake of breaking it and c) is about as relevant as hot air when it does not really cover the broken code. So right now I have a system that can be unresponsive for hours at an inconvenient time for the simple reason that a) the people behind systemd don't know what they are doing, b) don't give a fuck or c) are constantly high on some weird substances that give them visions. Neither of these reasons make them sympathetic and the consequences make people unhappy.

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

[Anonymous Coward]

not entitled, experienced.

and, we don't like the solution because it sucks and the systemd fanpersons tell us we're stupid ignorant dinosaurs for not climbing on their bandwagon. all as we watch that bandwagon crush more and more things that used to work just fine, thank you, IF YOU KNOW WHAT YOU ARE DOING.

Re:It's all Gnome's fault

[Anonymous Coward]

Fixing, or nuking from orbit?

Re:It's all Gnome's fault

[Anonymous Coward]

That's my take on it as well. Basically, poorly written stuff like PulseAudio doesn't properly shut down when you log off.

Wait, but didn't Pottering make PulseAudio...

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.

Systemd always leaves my sessions open

[Anonymous Coward]

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

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

[Anonymous Coward]

but it is a problem for people who are seriously using Linux, especially in a business setting

Serious users know already the use cases for the installation. Configuring just what is needed and disabling anything else is just a benefit, not a hassle. A business user who cares for the quick installation is likely a smaller business user wanting to replace a Windows desktop. In that case the problem is solved with a suitable Linux or BSD distribution.

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

[sjames]

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

frost pist! ?

[Anonymous Coward]

ransom for their re7el Pin our gay

Re:frost pist! ?

[Anonymous Coward]

That describes systemd as well as anything else I've ever head.

Makes sense ... but ...

[Anonymous Coward]

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.

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.

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.

Re:Makes sense ... but ...

[Anonymous Coward]

*nix has cron. You've heard of it, perhaps?

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:Makes sense ... but ...

[Anonymous Coward]

Whether I am logged into the machine or not is irrelevant - what is relevant is whether or not I have work for it to do. If you want to constrain resource consumption there are solutions to that via quotas.

Re:Makes sense ... but ...

[Anonymous Coward]

To the GP:

This assertion also completely ignores cron...you know the facility allowing users to run processes on a machine that they may or may not be logged into.

Oh and thanks for telling us how our machines "SHOULD" work in complete ignorance of how they have been used for decades. Geez that's some big balls you have.

Re:Makes sense ... but ...

[Anonymous Coward]

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

Wrong.

Right now, I can SSH on my home computer, my NAS, my raspberry PI, or any VMs on a server I rent, from my phone, launch a nohup/screen command and close the ssh session in 20 second. The same syntax, regardless of the distro running.
The command will run, whether it takes 10 second, 10 minutes,10 hours or 6 months.
Keeping the ssh sessions alive for the duration from my phone is obviously not an option.
Now, I could remember which VM/computer run systemd and which does not and adapt my previously universal commands, or rewrite all my scripts with conditionals, or remember to set up the conf file at install and pray it doesn't get overwrote at some time ... or systemd could avoid changing 40+ years default
  behavior.
I can easily see setups where killing all process at logout make a lot of sense, and having it as an option is a good thing. Forcing it as a default is not.

Are you saying...

[Anonymous Coward]

... systemd is less than perfect?

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

[Anonymous Coward]

Changes like this confirms that the developers are a narcissistic bunch of dicks which grew up with Windows 95, and thinks that's the way all computers should work. They know *nothing* about UNIX or Linux nor do they care about anything outside what happens on their own computer.

In the old days a fair bit of open source was rooted in a kind of altruism. Today, it's all about the ego and the money.

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

[Anonymous Coward]

They do not dogfood Linux on their desktops.

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

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]

his isn't just an inconvenient change, it breaks the expected and decades old behavior of how Unix machines work.

Which they don't care about: they're infamous for not just not knowing but not caring about principles, the architecture, history--"just old idiots whose choices interfere with the desktop!" type "thinking" (attitude). Hence Linus suspending a systemd dev a while ago--a$$hat kept breaking the Linux kernel in order to hide how horrendously awful systemd code is, even to the point of redefining reserved names and misusing them in the kernel (then ranting that Linus et. al. were stoopid/too old/behind the times/linguistic imperialists for maintaining the common definitions rather than allowing himself to dictate the name to the entire pre-existing userbase).

It's just a matter of time before the psyop from RedHat intensifies to out Linus and company: start leaving RedHat now, and funding the key devs and projects which have people who are willing (and will prove it/show it) to get and stay independent, and who have enough control in the projects that they can't be politically undermined.

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

[Anonymous Coward]

That's the whole point of Systemd: It's doesn't recognize competing solutions. Set limits under /etc/security/limits.d? Too bad, systemd won't honor them! For some bullshit reason of course. Now you have to put the same information in on a per-'task' basis. This is just another example of systemd discarding the existing solution, again for some bullshit reason.

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

[Anonymous Coward]

Why non trivial?

Re:Pure Insanity

[Anonymous Coward]

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

It will all become clear once systemd starts auto-installing Windows 10...

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

[Anonymous Coward]

It's easy as fuck if you actually engage your audience and get their opinion. That doesn't mean every distro has to be democratic, but you can't even make an educated guess on what to make a default unless you know what your userbase is like. Asking for opinions on a public mailing list is not asking too much. As a package maintainer I would absolutely field user opinions before making any decisions on that shit. Moreso if the package I'm maintaining is used by people who hate the alternatives.

Thankfully, the systemd bit can be changed in /etc/logind.conf, but why couldn't they have included a notice? Gentoo has a news system where developers can convey to users if there are any big changes, and they often include *how* to maintain the old behavior. That's how you do a distro.

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

[Anonymous Coward]

This is the exact reason why I went from Slackware to Debian, and then back to Slackware again. Many people said I could simply remove systemd and use some non-default settings. However, it was the development team's decisions which make me feel insecure to rely on.

Re:Pure Insanity

[Anonymous Coward]

Actually, the main Debian/Ubuntu systemd guy is on record liking the change. But there is now enough fo a stink raised that he is reverting it for the Debian package...

Re:Pure Insanity

[Anonymous Coward]

Very odd, given that said directory is configuring PAM and systemd is highly reliant on PAM for its user tracking.

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.

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.

tmux and screen

[Anonymous Coward]

So will it also kill tmux and screen sessions??

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

[Barsteward]

apparently you know nothing about systemd's config

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

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

[Anonymous Coward]

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

Funny. I do this all the time. Lengthy jobs, temporary daemons testing stuff. I use screen and tmux all the time. The statement above is complete nonsense. It only makes sense in a GUI setting.

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

[Anonymous Coward]

You mean users like mysql, apache/nginx/www, poostgres/pgsql, whatever? Are you serious?

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

[Anonymous Coward]

Not on real OSes. Now head on back to your Win10 or xbox and let the big boys talk.

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.

Nothing... It's racist.

[Anonymous Coward]

https://en.m.wikipedia.org/wiki/List_of_ethnic_slurs

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

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

[Anonymous Coward]

multi-user? the problem starts at user. definition: someone using the system to run their software. seems to be someone to be entertained by what the system provides these days.

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.

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

[Anonymous Coward]

That includes Debian, Redhat, and Ubuntu.

Re: Systemd is *more than* a pain

[Anonymous Coward]

couple that with virtualizing fs and the user has no ide what he is doing or where he is doing or where anything loads up anything. which would be fine if for example 16.04 ubuntu wouldnt have fucked its update system on the first go and broken unity for the main user in under 2 hours. the pos would also let it to install on a fs it couldnt boot from.

Re: Systemd is *more than* a pain

[Anonymous Coward]

Ubuntu jajaja. Noob.

Re:Systemd is *more than* a pain

[Anonymous Coward]

... Systemd is a pain ...

Basically systemd is built on a totally fucked up concept

"systemd" is a whole universe by now. I don't see any unifying concept behind that. The unifying principle appears to rather be being built by a totally fucked up crowd. The kind of only child that broke everybody else's toys on the playground and pushed them head-first in the sand, then complained to the parents that the other kids didn't like them.

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

Poettering boy

[Anonymous Coward]

why does he have such a following at Debian? Is he the devil or what? What an idiot.

only a dumb fuck runs daemons as a user

[Anonymous Coward]

fuck em

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

[Anonymous Coward]

I had this happened to a PFSENSE upgrade. It made me very unhappy because I had no internet thanks to them. Luckily, I was able to download pfsense through my cellphone and copy over all the files, problem resolved. But it wasted 2 hours of my time. I never had this problem before, I can't believe that every upgrade, be it Windows, linux or BSD, you have a high chance of something breaking, where before it would never happen.

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

[Anonymous Coward]

if you don't like gentoo then try arch or antegros

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

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.

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

[Anonymous Coward]

or Void Linux....

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

systemD, breaking Linux one release at a time

[Anonymous Coward]

WTF!? Do one thing and do it well.
Every year Linux turns more into Windows.

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

[Anonymous Coward]

Parent modded currently as +5, Insighful, my rectum... +5 Anti-SystemD sounds more apropos.

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.

You forget: FreeBSD also gives precisely the same as SystemD does:
the need to learn a new system. Both will look sortof familiar, but both will bite you when you least expect it.
True, FreeBSD questions have a wealth of answers on the 'net. But I'm sure SystemD questions will get answered too, especially now that all major distros are going SystemD.

OMG, I can not think on a worst solution

[Anonymous Coward]

so, everyone is saying: "never mind, is configurable" but:

- somehow it is the default option, changing how debian worked from the beginning

- not only that: is sending a clear message to the bad programmers that made this a necesity in the first place: dont worry about closing your deamon, systemd will do it... and a couple of years into the future all the gnome daemons will remain alive so no one will really have the option if using say pulseaudio (I say gnome because I think they are the suckers that left garbage running without a purpose)

BIG FACEPALM

PS: I wasn't a hater of systemd until now

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:One simple rule

[Anonymous Coward]

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

That is intentional because the very core philosophy of Unix is broken. Broken. Broken, broken, broken. Like a broken record. Broken. BROKEN! Muhahahahahahahahahahahahaha, broken. That's a nice broken system you have there. Wouldn't it be a shame if someone were to fix it? Muhahahahaha, broken. Let's fix everything, eeeeeverything. Bri, bra, bro-ken, I smell the core of an initd. Be it alive or be it dead i'll run a systemd instead.

systemd violation, core philosophy dumped. Muhahahahahahaha. One daemon to bring them all and in the darkness bind them. Slagt ham! Slagt ham!

SEE ALSO
              The systemd Homepage[8], systemd-system.conf(5), locale.conf(5), systemctl(1), journalctl(1), systemd-notify(1), daemon(7), sd-daemon(3),
              systemd.unit(5), systemd.special(5), pkg-config(1), kernel-command-line(7), bootup(7), systemd.directives(7)

Don't break user space

[Anonymous Coward]

Don't break user space. I wish Linus would come down hard on Poettering.

Having said that, you know I hate what systemd did here. But Linux's "one size fits both server and desktop" approach is also to blame.

Most distros come optimized for servers. A different set of kernel parameters would make for a more responsive desktop system, but I need to dig around the internet. How about asking whether a new system is best described as a desktop, laptop, or server? How about having packages that have settings and even patches for specific machines?

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

[Anonymous Coward]

Alpine Linux. The default for Docker, very simple, light and configurable.

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.

The problem systemd fixes

[ACE209]

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

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

[Anonymous Coward]

much of the FreeBSD code is released under truly free BSD family licenses, rather than the far more restrictive and less-free GPL family.

As an (mainly) end-user: go fuck yourself you selfish prick. The BSD license is only "less restrictive and more free" than the GPL if you wish to lock up the code. The only thing the GPL does is put the onus on the entire chain of developers to give their (shitty) code to us poor sob end-users, so if the worst case happens we can try to save ourselves.

Install Amazon Linux and be free from systemd???

[Anonymous Coward]

Is it possible to install amazon linux on a machine? It seems that is still systemd free, and its a very good distro for servers....
Anyone?

Sounds like a Windows problem

[Anonymous Coward]

You will now be upgraded.

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.

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

[Anonymous Coward]

But its perfect for the GIMP.

Debian without systemd

[Anonymous Coward]

If you want Debian without systemd:

https://devuan.org/

*slow clap*

[OrangeTide]

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

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

[Anonymous Coward]

OpenRC wasn't considered. At all. It was rejected as because it was shell script based.

Re:Systemd

[Anonymous Coward]

OpenRC is all the problems of shell scripts and all the problems of C libraries (90% of OpenRC is in C, last I checked the GitHub repo), minus the features of systemd. OpenRC scripts are almost as large a departure from SysV as systemd. It's got cross-platform support and it's slowly accreting systemd features, and that's about all you can say for it.

It is a complete falsehood to say that it wasn't considered. It was considered and rejected, and again, the arguments for and against it are still on the Debian wiki. My condolences for your narrative.

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.

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.

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.

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.

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.

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

[Anonymous Coward]

Any business running GNU/Linux won't have a problem using Slackware or Gentoo to build a "standard image" to then push to every workstation in the campus. Accompany that with a central "package supplier" (especially for Gentoo) machine, and all workstations can be upgraded (via binary packages, no less!) from a central packaging server that is maintained separately and can have VMs or other local machines used as testbeds before deployment.

No competent business will have trouble using more granular distros, unless they simply can't attract people that know that stuff. And that's not a failure of {Slackware|Gentoo}, but the company.

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

[Anonymous Coward]

"Hey, here's a piece of GPL code I want to use in my MIT-licensed software project.

Wait, I need to relicense my project to abide by the licence? Urgh."

TROLZ KNOW HOW TO GET ATTENTION

[Anonymous Coward]

this is the highest end unix trolling of the decade of all time

fixed in debian?

[lcall]

https://bugs.debian.org/cgi-bi...
says "The option has already be[en] reverted in the packaging git."

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

or Gentoo - with OpenRC goodness :)

[Anonymous Coward]

or Gentoo - with OpenRC goodness :)

https://wiki.gentoo.org/wiki/P...

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:Why not use a dialog prompt?

[Anonymous Coward]

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.

Yes, sitting in front of a desktop computer running a graphic interface, your solution would work.
But ssh on a remote computer, nohup somecommandthatwilltaketimetorun & , close ssh session ... no popup there !

I don't know about you, but for me the second case happen daily, the first, rarely.

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

[Anonymous Coward]

FreeBSD is lacking in a few areas on notebooks:
-hardware support lags too far behind;
-wireless is unreliable on Intel, Atheros and nearly non-existent on Broadcom;
-good luck getting a touchscreen working.

I tried to move my home network to a homogeneous FreeBSD environment a few months ago, but had to roll the notebooks back to Linux. My wife got after me about the intermittent wireless, so FreeBSD had to go. I ended up going with Devuan because it's familiar, systemd-free and wireless works a treat.

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

[Anonymous Coward]

Is Devuan a thing? I though it is a joke project with a 4.5 GB netinst image (seriously, do they test *anything*?)

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.

a bit of FUD here - gentoo is great as is openRC

[Anonymous Coward]

a bit of FUD here - gentoo is great as is openRC

Re:Sorry but that's the normal behaviorostost

[Anonymous Coward]

The main objection point is: Why bother use a systemd-specific mechanism when the problem it's addressing has already a *NIX solution for that, and that had been working will for _years_? Almost all *NIX people will say that's what SIGHUP is for! And what nohup/screen/tmux is designed for of course! Adding an additional, systemd-specific API doesn't tell anything more than what catching SIGHUP is meant to tell. So it's useless effort, and reinventing the wheel.

And also refute a common argument about that "user processes running when user has logged out is a security problem": (1) True misbehaving/malicious software will adapt to this systemd way of keeping alive and continue to be misbehaving, so ultimately you will solve nothing. (2) If what you worry about is bad code of some other programs, then either tell the bad developers to fix them, or, if they are unlikely to fix or that you cannot trust them, use a local **whitelist** for users _and_ admins to decide which programs may be kept alive, and which should die after logout. This is the right way to do the "security problem", not yet-another-systemd-API crap.

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

[Anonymous Coward]

Again and again I've heard people say that Slackware is too "primitive" to use as a server.

Well, have you tried? I say it's bullshit.

I have used both Redhat and Debian as well as Slackware a lot on servers (and desktops, but that's not what we were discussing) and I have to say the distro with the most sensible defaults is by FAR Slackware. It's also very helpful that it keeps all programs in their default state, i.e. the documentation for each program like Postgres, Apache, dhcpd etc.. can be followed to the letter. Both Redhat and Debian all too often change stuff and move paths around so you have to look for Debian-specific documentation on how to do something.

I can honestly not find a single thing that's been harder to do and manage on a Slackware server compared to Debian and Redhat, and a lot that's easier. The fact that Slackware is a lot more stable then the others is also a huge advantage. You can rely on your scripts and programs to keep working under Slackware, not so much on other distros.

Creating their own jobs

[Anonymous Coward]

Why do the systemd folks think they need to keep reinventing the wheel?

That's easy: they're creating their own jobs, rather than being told what to do. And I fully understand why a person would want to do that. What I don't understand is why Red Hat and everybody else simply rolls over and takes it.

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

[segedunum]

The sensible arguments just keep getting better :-).

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.

akin to Windows

[Anonymous Coward]

fuck all your cars up, ride our bus

systemd is a bad idea.

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

Reverted already

[Anonymous Coward]

If nobody's mentioned it yet (not reading through 900+ posts), this behaviour was a) easily turned off and b) reverted (i.e. made non-default) after couple of days.

But I expect it'll still be quoted as a reason systemd sucks in 2 years time.