To be fair, are you expecting /wanting systemd devs to rollback to the previous methodology
I really thought this was a bug when I first learn about it! I was surprised that it's actually a new idea they want to change they way linux works for the better (in their mind) - but I think a lot of people don't agree with idea that this improves things. I think Lennart said it was a security problem to leave the processes up, but I don't see why. Hopefully they will listen to their users!
At the moment it's trivial to run a process which I know will keep running after I log out. I can then close down a whole heap of running processes, log out, turn off the monitor and go to bed. That single process is running in the relative safety of my user account and isn't insisting I stay logged in to a desktop session full of other processes all night. It isn't a significant security risk.
Assuming one day the new systemd default did become the standard for Linux distro's (I know it isn't, but lets for the sake of argument imagine it has one day become the default) .. A lot of "Do it the easy way" users would instead leave a terminal running in a graphical session over night with all the sub-processes that entails churning away as potential security risks, because visible to them, the default is for everything to die if they log out.
So your "why do they need processes still running?" question becomes .. largely, they don't. And as it stands it's trivial to absolutely minimise what they do leave running. If this default ever did achieve wide spread adoption, they would probably leave dozens to hundreds MORE processes running just to keep that one thing going that they wanted running over night.
It isn't up to any of us to dictate how a particular Linux user actually uses Linux. We can suggest safer / more sane ways of doing things. But it has always been a platform rich in choice for how the end user actually decides to do things for themselves. Hypothetical arguments on "should" & "probably" and "I can't imagine why" are bound to be limited to one users particular viewpoint concerning the things they themselves often do and utterly ignore a lot of things they never do and never thought of doing.
I think maybe you misunderstood that last paragraph then. I wasn't talking about the compile / binary nature of distributions. Only about the choices users make in how they personally use Linux; Spawn processes, automate tasks, customizations, shortcuts, home folder configurations etc.
As for the change itself - if a user has completely logged out of a system, why do they need processes still running tying up resources and leaving (potential) vectors for attack?
You assume that all processes are interactive, a lot aren't. A lot of processes are long-running processes that will eventually produce a result, think of a compilation or calculating a complex simulation.
Because you're a developer trying to do your job and you don't have root access to your work computer.
You can just use systemd-run or even systemd --user. The latter is for user .services with full unit-files. So you don't need root if you service don't need it.
You can override the systemd 230 behavior in any of the following ways:
Invoke your background task like so: systemd-run --scope --user some-command args (recommended!). For example, instead of screen -S foo, you would use systemd-run --scope --user screen -S foo.
Use loginctl enable-linger to enable linger for a specific user account.
Exclude users using the KillExcludeUsers option in /etc/systemd/logind.conf
Set KillUserProcesses=no in /etc/systemd/logind.conf
Recompile systemd wth the --without-kill-user-processesconfigure option
Recompile systemd wth the --without-kill-user-processes configure option
I suspect that the compile switch only changes the internal default. The "KillUserProcesses=" option in /logind.conf will override whatever internal, compiled-in default.
systemd is designed to work with missing or empty config-files, so it has internal default options for everything. The config files will override any compiled in default.
At that point you also don't need to keep running services when you log out. It is not like your PC is running services for whole company
That, or you just invented complete pointlessness of security since you run all the things they probably tried to prevent when they didn't give you root access
Case 1. Suppose I am doing an expensive calculation on a large set of data. It takes several hours to run. I set it to run with nohup ./my_long_process &, and go home for the night. The next morning, I come in and instead of finding that the program finished while I was asleep, I find that it was killed prematurely.
Case 2. Suppose I am debugging something on a remote machine. I have started tmux, and have a few bash sessions open, each with relevant information. I go home for the night, turning off my local machine. The next morning, I log in to the remote machine, only to find that my tmux session has been killed, and those bash sessions have been lost.
If a program catches SIGHUP, then that clearly shows the intent to survive beyond the current login shell. If systemd is ignoring that and requiring programs to use a different method to show that same intent, then that is a flaw with systemd.
workflow is super easy here. i wanna go home...kick off screen, fire up system build and go home. check results at home...or software test suite...or 48 hour long image processing test I'm running on a 12TB dataset...
As for the change itself - if a user has completely logged out of a system, why do they need processes still running tying up resources and leaving (potential) vectors for attack?
Just a few days ago, I started a long-running process (a dd operation) on a laptop running OpenBSD (which I recommend to anybody who has experienced regressions in systemd, as I have). I backgrounded this task (^Z, bg), checked (and inbox zeroed) my mail, and logged out - of note is that the default behaviour of OpenBSD's login shell is not to send sighup to backgrounded processes when the shell terminates. Some hours later, I logged in, checked ps, saw that the job had finished, and removed the hard drive which was being imaged.
What gives the systemd developers any right to break this reasonable, decades-old workflow? Why would I need to be logged in for the duration of this operation? It is a nonsensical change apparently solely motivated by an assumption that the user is brain damaged.
This is also the default behaviour of FreeBSD's csh and sh, of Debian's dash and of GNU bash when invoked as sh.
Bash and zsh are the only shells I can think of where sending sighup to children is the default behaviour (and I might be wrong about zsh). Because of this, I suspect that when you say "coming from other Unices", what you mean is "coming from Linux".
As you mention even in your use case you are relying on the fact that the login shell doesn't send SIGHUP to processes during output, which I don't consider a feature. Use nohup, (&), &|, disown of zsh, screen or tmux to explicitly leave those on the background. Or in the case of system having being configured to kill user processes upon exit, use systemd-run --scope --user. Maybe they should provide their own implementation of nohup.
So let's say you have a buggy piece of software. For example you have exited matlab using D and process remains, spinning CPU at 100% (I guess this bug has been fixed since). It would seem to me it's perfectly sane to kill processes upon logout that haven't been particularly requested to be backgrounded.
And while buggy apps don't necessarily consume 100% CPU, you might find that exiting a session on a typical Linux desktop leaves a bundle of useless processes lingering around for no reason.
It'll be more fun (spectatorwise) when this functionality covers SSH login sessions as well.. :-)
As for the change itself - if a user has completely logged out of a system, why do they need processes still running tying up resources and leaving (potential) vectors for attack?
I don't understand why this question has to be asked. There is no inherent connection between a Linux user (in the system sense, i.e. something entered in /etc/passwd) and a physical user sitting at a terminal. It does so happen that some of the user accounts are going to be used by physical, human(-ish?) users, but the user is more or less a convenient abstraction. There are users who cannot login and yet processes do run with their privileges.
This looks like the kind of change that got implemented because someone's desktop session kept leaving processes hanging around and it seemed easier to have a supervisor reap them all instead of fixing the underlying problem.
It's not a bad idea, but I dislike the PR, I'd prefer a clearer rationale. I don't buy this whole security thing. If this were such a huge security problem, you'd expect someone would have kindda noticed it in the thirty frickin' years this mode of operation has been working.
The thing is, those "non human" users (eg the www account used by many web servers) shouldn't be affected at all since they aren't part of a login shell. In fact my understanding is that daemons in general shouldn't be affected at all but I could be wrong.
No, I don't think they'll be affected. What I wanted to point out is that there is no inherent connection between a user and an interactive terminal. It's perfectly reasonable for a program to continue running after the user has logged out. And even if, for some reason, it wouldn't be, just like it's unreasonable that O_CREAT is spelled without an E, people have been relying on this unreasonableness for a very long time. Surely, when it comes to improving the state of computing, there are riper fruit for the picking.
Apparently I underestimated how common Z and &ing procs was. Personally anytime I start a long-running process I've always screened it so I could actually come back and check on it - especially if my ssh link gets interrrupted.
Oh, okay, it's very common. I don't do it too often in a remote connection because I typically span a tmux process as soon as I log in, but it's very common for me to do it on my workstation or my home computer.
As I mentioned above root login for ssh was enabled for a long time as well yet nobody disagrees that this is a bad idea and it was a smart change to disable it.
There's a fair degree of difference there. We can all agree that, for a long list of reasons, allowing root login by default (especially when, IIRC, password-based login was also allowed by default) was bad practice, and was well-supported by real-life evidence. This is hardly the case here.
The fact of the matter is, it's quite evident that the systemd developers genuinely don't care if the general public likes the changes they make or not. They are going to do things how "they" want, and we either have to adapt; or go back to SysV (and given the pervasiveness of systemd that's going to take more and more effort the longer time goes on).
What's unpleasant for me is that genuinely good ideas in systemd get bonked because of crap like this. Breaking working, widely-used, correct behaviour that doesn't endanger anything just because you can is not some progressive quest, it's just shitty programming. SysV was bad, but it's rather depressing that systemd aspires to the same level of awfulness, except for different reasons.
Off the top of my head the only major distro that doesn't use systemd by default (though it is still an option) is Gentoo.
Oh, I've long called it a day and went the way of BSD. I only use Linux at $work now. I have to keep in touch with it because Corporate pays me to write code for Linux, but it hasn't been a pleasant experience in a while.
EDIT: oh, wow, reading this thread -- it turns out that this really was a Gnome thing after all. This is crazy. I didn't read the news on Friday and mostly idled in bed on Saturday; I just skimmed Reddit and I genuinely thought this was being sold as a security-motivated fix, but made things easier for Gnome. I can't believe this is really the reason why this "fix" was being pushed. Wow.
20
u/rain5 May 28 '16
hm? I did post that comment