Systemd 230 Is Upsetting Some Over Its KillUserProcess Setting

[sjukfan]

Sometimes I wonder if the systemd people live off of drama. People have used nohup since forever to make sure processes keep running after they log out, and suddenly they change it. How can they not foresee that people will complain about this? Sure, people can prevent this with KillUserProcesses=no or systemd-run but a change like that should come with a huge <blink>-tag to alert everyone about it. Instead of like now, suddenly be there and people wondering why things isn't working like they expect them to.

And yes, but no. Not everyone read all the release notes for all new software versions. So telling them to read them isn't really a solution.

[starshipeleven]

a change like that should come with a huge <blink>-tag to alert everyone about it.

specify "everyone". Do developer need to figure out who is using their stuff in certain ways and send them a mail?

This is a distro maintainer thing, knowing what is used and how in your distro and making sure that updating things will not upset users. And also RTFCL (read the fucking changelogs) before publishing the package, and informing their users is a distro-mantainer's job, not upstream developer's.

Arch and others have already signed the "i want all new software with as little tampering as possible" so they get this in the face if they don't read changelogs and stuff, but they agreed to it so it's fine.

[CanalGuada]

...

In a "sane and secure" setup, running code after user logouts is a system more protected operation. If any random code can decide per se to override any system policy, staying around even if not allowed to, then you can't enforce security. Other people really want to, thus things go now a little bit less liberal, even if software like tmux expects to be unrestricted there.

There are ways to workaround this "issue" without many changes. For instance, asking admin to autostart tmux with systemd in a detached (from logind user session) session for your user.

https://wiki.archlinux.org/index.php/Tmux#Autostart_with_systemd

With user sessions and scopes paradigm being now mainstream, one should expect that distinguish running software background but inside user session and running software background outside of it with some more privileges is a requirement. Here we are.

(English is not my native language. But I guess there is no need for this full disclosure.)

[waxhead]

Regarding this issue here ... systemd is not actually breaking compatibility - the configuration of systemd does. The faster boot time for systemd is not noticeable and is mostly worthless for desktop and small server use, but it makes a big difference if you are firing up a large server with a hairy configuration that brings up (or down) a lot of other stuff. systemd both makes things easier and more complex than before. All over it is more benefits than drawbacks at least the way I see it, and as far as I know people are free to fork systemd anytime they want and restore what some refer to as sane defaults. Instead of wasting energy on complaining try to improve the darn thing. As for this specific case , I don't see the problem - open a text editor - change the config and move on... changing the config takes less energy than to write comments like this so there

[starshipeleven]

people are free to fork systemd anytime they want and restore what some refer to as sane defaults.

Same as above, this is technically the distro mantainer's job (making sure that all applications have sane default configs regardless of what the developer thinks), it's just setting stuff in a config, a fork is a bit too much.

[interested]

Sometimes I wonder if the systemd people live off of drama.

I rather think the drama is created in other end.

People have used nohup since forever to make sure processes keep running after they log out, and suddenly they change it. How can they not foresee that people will complain about this?

All they did was to change the _recommended_ default. Upstream systemd doesn't change a single config-line in the actual distros; the distro maintainers are in sole charge on how they configure systemd.

Sure, people will complain when their work flow change. But really, in tech such stuff change all the time, and in this case, for an arguable better and safer solution. People complained too when "Telnet" was replaced with ssh. There are no pleasing all people.

Sure, people can prevent this with KillUserProcesses=no or systemd-run but a change like that should come with a huge &lt;blink&gt;-tag to alert everyone about it. Instead of like now, suddenly be there and people wondering why things isn't working like they expect them to.

And yes, but no. Not everyone read all the release notes for all new software versions. So telling them to read them isn't really a solution.

I find it a telling development that people that knows what "nohup" is, are installing or upgrading an OS without reading release notes. Even people deploying production servers apparently do that. No wonder business's are fleeing to the cloud. As some said: "I prefer a good IT team, but take the Cloud as a second best option".

Anyway, the real riddle is this; Should Linux change over the next 10-20-30 years, or should all features and work-flows be frozen in time as for this moment?

As it is now, people are shouting for preserving a bad old, hackish Linux behavior that have resulted in countless security problems and instability problems galore. All because they apparently find it too taxing intellectually to type "systemd-run --user -scope *program*" instead of "nohup *program* &".

[interested]

Sometimes I wonder if the systemd people live off of drama.

I rather think the drama is created in other end.

People have used nohup since forever to make sure processes keep running after they log out, and suddenly they change it. How can they not foresee that people will complain about this?

All they did was to change the _recommended_ default. Upstream systemd doesn't change a single config-line in the actual distros; the distro maintainers are in sole charge on how they configure systemd.

Sure, people will complain when their work flow change. But really, in tech such stuff change all the time, and in this case, for an arguable better and safer solution. People complained too when "Telnet" was replaced with ssh. There are no pleasing all people.

Sure, people can prevent this with KillUserProcesses=no or systemd-run but a change like that should come with a huge <blink>-tag to alert everyone about it. Instead of like now, suddenly be there and people wondering why things isn't working like they expect them to.

And yes, but no. Not everyone read all the release notes for all new software versions. So telling them to read them isn't really a solution.

I find it a telling development that people that knows what "nohup" is, are installing or upgrading an OS without reading release notes. Even people deploying production servers apparently do that. No wonder business's are fleeing to the cloud. As some said: "I prefer a good IT team, but take the Cloud as a second best option".

Anyway, the real riddle is this; Should Linux change over the next 10-20-30 years, or should all features and work-flows be frozen in time as for this moment?

As it is now, people are shouting for preserving a bad old, hackish Linux behavior that have resulted in countless security problems and instability problems galore. All because they apparently find it too taxing intellectually to type "systemd-run --user -scope *program*" instead of "nohup *program* &".

[balouba]

i like that it kills user processes. it how it should be. terminate a session, it has to be terminated. unclean setups gotta clean it up.

[kobblestown]

i like that it kills user processes. it how it should be. terminate a session, it has to be terminated. unclean setups gotta clean it up.

OTOH, things like ssh-agent and screen should work as they have worked so far. Frankly, I don't care how it's implemented. Maybe both have to be made systemd-aware. But there's nothing wrong with starting screen on a remote machine and being confident that if the connection drops your stuff is still running.

Also, I'm not sure what problem is this supposed to solve. I've never had issues with processes not being cleaned up after logout. Except for the ones I expect to behave like that - again screen and ssh-agent.

[nanonyme]

That whole boot-up time argument... the one person I know in person who actually used that as an argument for systemd saw me boot from a USB stick with sysvinit on Debian wheezy, and accused me of using a fast USB3 thumb drive to get the boot speed I had. Nope, just plain old USB 2 thumb stick I got for free at a dev conference at some point (with the Microsoft TM on it - so it's well suited for a bootable Debian install!).

Even if on old systems with mechanical HDDs where a few seconds might possibly be saved... it's not an argument for the massive (and always increasing) scope systemd is trying to fill. I too am in the process of tinkering with GuixSD, and expect to switch when it's more mature - probably late this year or next year.

It's not just the speed though it is fast. Systemd automatically generates metrics on boot speed that you can use for analysis on how to speed boot up. Most of the bottlenecks are in various services but with sysv it was rather difficult to identify the guilty party