>I would call signal(SIGHUP, mysignalhandler) to be an explicit ignoring of SIGHUP.
But that doesn't explicitly ignore SIGHUP. You're explicitly handling it but from an outside perspective we don't know if your SIGHUP handler is supposed to be a no op, output some progress information, terminate the program in some special way or what. All the system knows is that it signaled your program and your program is still around 10 seconds later. In terms of your program, it hasn't taken any external action, hence not being explicit.
As for the Gnome project though, that's just an example. I'm talking about cases where the application should terminate upon receipt of SIGHUP but doesn't. That default isn't changing, the method to avoid the default action is. Back when SIGHUP was created all software that wanted to ignore it needed to make a handler to avoid the new default behavior. If you want to be able to kill misbehaving processes that were supposed to terminate on SIGHUP then the design needs to change. There's no way to fix this without making some breaking change.
As to requiring others to work with it, your distribution is the one that's making you do that. systemd upstream has had killuserprocesses for a while now. It's just a configure option when building systemd. It's not like your distro is having someone else build packages for them, setting appropriate config options is entirely on them. Some distros are building systemd with that on by default, and some aren't.
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.
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.
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.
Yeah but that's exactly the same situation we're in right now with distros turning on KillUserProcesses. I can start whatever processes I want to in another scope without having to modify those processes.
... but not with general-purpose tools that use the standard semantics that have been around since 7th Edition. Only with Linux-specific and systemd-specific tools. Which is why it of course is not the same situation at all.
As for the Gnome project though, that's just an example. I'm talking about cases where the application should terminate upon receipt of SIGHUP but doesn't. That default isn't changing, the method to avoid the default action is. Back when SIGHUP was created all software that wanted to ignore it needed to make a handler to avoid the new default behavior. If you want to be able to kill misbehaving processes that were supposed to terminate on SIGHUP then the design needs to change. There's no way to fix this without making some breaking change.
As to requiring others to work with it, your distribution is the one that's making you do that. systemd upstream has had killuserprocesses for a while now. It's just a configure option when building systemd. It's not like your distro is having someone else build packages for them, setting appropriate config options is entirely on them. Some distros are building systemd with that on by default, and some aren't.