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.
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.
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."
> Weirdness is in the eye of the beholder
It's a windows acolyte mindset. Many people don't imagine that a login is just another program, rather than the parent process.
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 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.
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.
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.
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.
Oh my god the number of times we had to bounce systems because the unintended background processes of long gone users overloaded the system.
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).
systemd brought nothing to this arena.
