3 ms·

So, if I understand correctly, a misbehaved program that incorrectly ignores SIGHUP will be replaced by a misbehaved program that starts a new user scope with s

So, if I understand correctly, a misbehaved program that incorrectly ignores SIGHUP will be replaced by a misbehaved program that starts a new user scope with systemd. In both cases, there is no way to tell whether the program has hung, or whether it is working as intended. The end result is the same. So, we've switched to a new API, broken all existing daemons, for no end benefit? I'm fine with having KillUserProcesses exist as a concept. There are some odd machines, like public terminals, where you would want to forbid any long-lived processes. I'm not okay with it being the default option. Yes, the distributions can change their default, but systemd's default in an endorsement that shouldn't be there.

MertsA 9y ago
No, that's not the concern here. KillUserProcesses is intended to reap children that were never intended to persist outside of the user session. My ssh-agent is never going to move itself into a new scope, but it very well could have a bug that causes it to hang around after I log out. The only things that will ever create a new scope are things like tmux, screen, and maybe some variant of nohup. Here's the kinds of problems that misbehaving processes actually cause. https://bugs.freedesktop.org/show_bug.cgi?id=94508#c10 https://bugs.freedesktop.org/show_bug.cgi?id=94508#c10 And yes, KillUserProcesses reliably fixes crap like "hp-systray" from hanging your whole session in a way that isn't obvious to the user. If there's a deadlock when trying to log out, somethings gotta give otherwise your session will just persist forever.