This is such a classic example of the type of argument I see from most anti-systemd proponents that it made me laugh out loud when I clicked your link.
For the lazy, here's the context of that cherry-picked sentence:
> In order not to break screen we currently do not set kill-user=1 or
kill-session=1.
> Note that in some cases it might be a good thing to kill screen sessions when the user otherwise logs out (think university, where students not logged in on a workstation should not be able to waste CPU), in other cases its a bad thing however (i.e. in yours). That means it must be configurable whether screen is considered an independent session or not.
1. Systemd did not solve any problems I actually had.
2. Systemd introduced problems that I did not have previously.
3. Systemd did not provide me any net benefit, that is, the few benefits it did provide over Upstart/SysV/etc. (easier service configuration and ordering) did not overshadow the issues it caused. Its introduction into my home and professional computing life has been a net negative.
My first experience with SystemD (Ubuntu 16.04 IIRC) turned into a frustrating experience, mostly around trying to mount a NFS volume in /etc/fstab, defined with 'soft' and 'bg' mount options. SystemD would often fail to mount the volume, and as a result would never fully boot to login prompt. Additionally, on shutdown SystemD would hang again forever trying to unmount that volume. No amount of mount option flag tweaking seemed to make much of a difference, so I simply removed the NFS volume from fstab and manually mounted when I needed it.
Happily running MX Linux today and back to mounting NFS in /etc/fstab.
systemd did make package maintainer's lives a lot easier. We don't often see the shift to systemd from their perspective. They are the ones making the distros so I think they are the ones who really get to say what goes and doesn't go in a distro. They don't have to keep maintaining long init scripts for the hundreds of packages that they are responsible for. Unit files are so much easier to deal with.
Yes, my systems are primarily operated for my benefit. This should not be a controversial stance, and certainly not one worth hurling insults about.
>Seriously - don’t use it if you hate it so much.
Oh how I WISH that were a viable option. Few things would make me happier than that overcomplicated, opinionated, arrogant pile of unsafe code being excised viscera ex machnia from any system I have the misfortune of managing.
Sadly I'm stuck with it if I want to run any mainstream Linux distros.
What benefit are you really getting from using mainstream distros if you find their choices to be so objectionable and don't agree with their decisions? And have you looked at the state of the kernel or at your CPU lately? I would really suggest not using Linux or any modern x86_64 processor if you are worried about "overcomplicated, opinionated, arrogant piles of unsafe code" at the lowest possible levels of your system.
>What benefit are you really getting from using mainstream distros if you find their choices to be so objectionable and don't agree with their decisions?
Well, that's an easy one: popularity = support. I dislike Ubuntu these days, but I run LTS on my work machines because no matter what obscure program I might need in the course of my job, it will almost certainly run on Ubuntu. Build instructions will target Ubuntu. Prebuilt .debs will target Ubuntu. Static binaries, or AppImages, will have been tested on Ubuntu. I get a choice between "install the snap, or build from source?" I can install the snap and get on with my day.
It's not inherently better in a technical sense, it's just overwhelmingly easier to swim with the current.
I mean that is their position yes. It’s a good default too since it’s weird that “logging out” doesn’t imply “and end all my programs.” This is basically the same behavior as Windows where anything not going through the task scheduler ends when you log out.
This is a feature that sysadmins have been asking for. On any multi-user system you run into this crap where background processes for users who are long-since gone just hang around forever because they do weird things or hang and ignored the signal. We implemented it ourselves with PAM but systemd’s solution is a lot cleaner.
And they’re not breaking any POSIX behavior. Nowhere does it say when the system isn’t allowed to kill a process.
> it’s weird that “logging out” doesn’t imply “and end all my programs.”
Weirdness is in the eye of the beholder. I regularly run programs whose lifecycles are not in sync with my login session. Why do I need to stick around to see a batch job complete?
I can understand that different folks have different backgrounds which changes expectations... but come on... somebody bringing up tmux, screen, etc. should simply end the conversation. "Oh, that is a common and historical use case that I have not considered, today I learned something."
Yes but that model conflicts with the human notion of being “logged in” to a system.
And the current behavior is literally what you describe. It’s just the quirk of subreapers being implemented recently that daemonizing a process wasn’t local to your session.
It makes zero sense that a process that double forks is reparented by init instead of your session leader. If how things worked currently was proposed today it would sound crazy.
>It’s a good default too since it’s weird that “logging out” doesn’t imply “and end all my programs.”
I have to disagree, I don't think I've ever run something where what I intend is "kill this mid-run if my connection drops".
>This is basically the same behavior as Windows
My recollection from when I used Windows Server (admittedly some time ago) is that the default behavior on connection loss or closing an RDP window is indeed the tmux-like behavior. The user has to click a separate "Log out" button, and even then, has to manually confirm that it's okay to kill anything left running.
> It’s a good default too since it’s weird that “logging out” doesn’t imply “and end all my programs.”
It may be a good default if you're starting from scratch, but GNU Screen has came out in 1987. (Poettering was 7 years old then.)
> This is basically the same behavior as Windows […]
Comparing it to Windows' behaviour is not going to win you any positive points with me. :)
> This is a feature that sysadmins have been asking for.
As a sysadmin this breaks my own daily workflow. I have 400 VMs that are treated as pets and I probably screen sessions on at least a third of them. (I have another 500 that are cattle-like.)
> And they’re not breaking any POSIX behavior. Nowhere does it say when the system isn’t allowed to kill a process.
Aka, malicious compliance. See also: nowhere does it say that the US President cannot fire the FBI Director. Also: nowhere does it say that the US Senate has to hold hearings when a US President nominates a judge for the US Supreme Court.
> This is basically the same behavior as Windows where anything not going through the task scheduler ends when you log out.
But when using remote connections, ie RDP, the default is that your session is disconnected. You have to actively choose to log out of an RDP session.
When using SSH I typically want the same. If I put my laptop to sleep or a networking issue causes the TCP connection to end, I want my terminal session to be restored when I reconnect via SSH.
Why exactly should students not be able to use CPU cycles while not logged in? I certainly did this as a student and would probably not have complained if it decided to kill my processes when doing so.
I don’t know if these even exist anymore, but I’m imagining a class that meets in a room of workstations. Students can login to any workstation in the room. In this kind of shared environment, you may not want to have a student start a screen session and use the resources of a workstation when they logout. They could be sucking up cpu time from the next person to log in (from the next class).
It’s a scenario that might make sense here. But then again, having a watchdog script just kill leftover processes has been doing this same job for forever. Including this use case in systemd seems like overreach.
Yeah, these still exist, though they're becoming more rare. I think what you actually want though is for processes to be killed at the end of class/lab period (even then, I think this should be done by students manually to avoid losing unsaved work). For example, say a student is running some big batch job as part of a lab. Now, if he wants to, say, go to the bathroom or go to the whiteboard to consult with other students, he has to either leave the computer unlocked (possibly leaving neighbors access to private student account data) or kill the running job.
Perhaps. I have worked half my career in academia & research, going back to when Solaris (SPARC) workstations were a thing, and this was never a problem.
You don’t deserve the downvotes. This is precisely the use-case this feature is good for. Multi-user systems where persistent background tasks for unprivileged users doesn’t make sense and is more indicative of a misbehaving program than a user trying to run a job.
Oh my god the number of times we had to bounce systems because the unintended background processes of long gone users overloaded the system.
While it's a valid argument, it's also a prime example of a special case that should not be the default - especially so because in my university, people were instructed to use the Linux workstations remotely for long-running tasks.
Sounds like you had junior admins at best leading your university's *NIX department.
A mid-level admin in 1995 could have easily made a 100 line script to kill background processes from non-logged in users that were running over three hours (or whatever).
I don't understand this angle. You acknowledge the functionality could have been useful even 25 years ago; it makes perfect sense for a daemon developer to integrate the functionality into a session manager and put it behind a config flag which is exactly what they did.
But that’s such a useless definition because then all software “provides nothing” since it’s implementation proves that you could have written it yourself.
logind is far more robust than any of the janky shell scripts
I’ve seen over the years to accomplish this.
The functionality to gracefully end long running background processes has been a part of standard killall, pkill, etc. for quite some time.
Even then, yes, the functionality of using ps and kill together has existed for 20+ years. Those tools are already implemented, providing the functionality for decades.
In no universe is logind considered robust, and basic scripts from middling UNIX admins have provided this functionality for decades, untouched. Even the "janky" ones.
See my comment below. These tools are fundamentally broken for this use case and have never provided the functionality needed. Bash scripts are not a process manager and it is incredibly wrong to try and make it work like one.
I responded to the comments below. These tools are not fundamentally broken, you're just ignorant in this space. They have always provided the functionality needed. Scripting can easily manage processes at a higher level, and it's basic functionality to make it work like that.
I've already been in a forest of bash scripts and I would not go back there again. I have no comment on systemd's implementation but the implementation you're talking about is also incorrect. It has never been safe to kill random processes using a bash script running in the background, on most Unixes (and Linux) it is 100% impossible to do that without race conditions due to the limitations of procfs. Doing "ps | grep" and "killall" is a footgun. You would need to implement this in C for it to have a chance of being safe at all, and even then, you would need to rely on system-specific functionality because there is no portable way in POSIX to actually do this.
>I've already been in a forest of bash scripts and I would not go back there again. I have no comment on systemd's implementation but the implementation you're talking about is also incorrect.
In certain cases I don't disagree, but systemd does not implement this feature correctly, so using functionality that's easily reviewable from decades past makes sense. If systemd could properly implement the feature, there would be no need for the scripting.
>It has never been safe to kill random processes using a bash script running in the background, on most Unixes (and Linux) it is 100% impossible to do that without race conditions due to the limitations of procfs.
This is hilariously wrong. Lots of UNIX OSes don't even implement the ps suite of tools by using procfs.
Even then, there were no race conditions in this use case anyway.
>You would need to implement this in C for it to have a chance of being safe at all, and even then, you would need to rely on system-specific functionality because there is no portable way in POSIX to actually do this.
It's already implemented this way on plenty of UNIXen. ps and kill is the POSIX portable way to approach this, so you're wrong about that as well.
Almost everything you said above is incorrect, or misunderstanding basic UNIX.
If you really want systemd to add this then I'm sure they will look at your feature request or PR.
I would urge you to actually check with your system instead of blindly dismissing me as wrong just because your bash script happened to work without error. In my experience BSD-based Unixes get it right and don't use procfs for ps or pkill. They don't have the problem because they use special syscalls for this. But SysV-based systems have historically used procfs to implement ps. Linux also still does. Try unmounting proc and running ps or kill and see what happens. If you can't do it then your system suffers from the problem, which is that you can't safely send a signal to the process after reading it because there is no guarantee that the actual PID will persist in between calls to read() and kill(). POSIX says nothing about this because it doesn't specify procfs, or how pkill should actually be implemented. This is all fair game as far as compatibility is concerned.
There is also the other more obvious race condition in your bash script which can also be pre-empted in between the calls to ps and kill. This can happen on any Unix and is not some big mystery either. PID reuse has been a known problem for decades and Linux finally got a solution to it a couple years ago with pidfd_send_signal. There is also the matter of cgroups but I am not going to get into that because I doubt you will want to hear about it.
>If you really want systemd to add this then I'm sure they will look at your feature request or PR.
The less systems touches the better.
>I would urge you to actually check with your system instead of blindly dismissing me as wrong just because your bash script happened to work without error.
Who said this was bash? The script from all those years ago worked perfectly without race conditions.
>They don't have the problem because they use special syscalls for this. But SysV-based systems have historically used procfs to implement ps.
Makes no difference, procfs works fine for this.
>Try unmounting proc and running ps or kill and see what happens.
You're effectively never unmounting procfs. Also, if you managed to, systemd would crash!
>If you can't do it then your system suffers from the problem, which is that you can't safely send a signal to the process after reading it because there is no guarantee that the actual PID will persist in between calls to read() and kill().
There's maybe 10 lines of code to ensure that logic. Again, middling sysadmin work.
>POSIX says nothing about this because it doesn't specify procfs, or how pkill should actually be implemented. This is all fair game as far as compatibility is concerned.
POSIX does say something about this; read about signals. You stop the process before killing it, and ensure that the start time is the same for the stopped process before the kill. That completely eliminates the race condition, using basic POSIX signals.
>There is also the other more obvious race condition in your bash script which can also be pre-empted in between the calls to ps and kill.
That race condition is eliminated with the logic above. That eliminates the PID reuse race condition, even if it's very rare.
>reuse has been a known problem for decades and Linux finally got a solution to it a couple years ago with pidfd_send_signal.
That functionality is where it belongs now, so instead of coding a logic every time you have to ensure PIDs, it's now handled for you.
>There is also the matter of cgroups but I am not going to get into that because I doubt you will want to hear about it.
Correct, I don't want to hear it from someone who doesn't understand POSIX and basic/intermediate sysadmin work.
at university I remember working around the auto-killing of logged out users processes by running screen, then inside that screen ssh'ing into localhost
Poettering:
> Note that in some cases it might be a good thing to kill screen sessions when the user otherwise logs out […]
* https://lists.freedesktop.org/archives/systemd-devel/2011-Ju...