This, exactly.

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.

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.

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.

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.

Beautiful.