Processes using daemon(3) have been around for 21 years, and are used to certain behaviour. Some of those processes behave badly.
systemd is adding functionality to kill all of a user's process when the session ends, no matter what. The problem is that they don't have any way of telling which processes are behaving badly and which ones aren't, so they're telling everyone (e.g. tmux, screen, etc) that they have to implement changes or they'll be killed too.
Fundamentally, the problem isn't whether the systemd behaviour is right, the problem is that it's a huge breaking change and they're asking everyone else to work around the shortcomings of their approach.
> shell managers like screen and tmux had hacks to make them survive sessions ends in the past
tmux, screen, etc. didn't have hacks to survive sessions; they just did, automatically, because of how things worked. systemd is asking the to add hacks to make them survive session ends from now on, when running specifically on Linux under systemd 230+, because systemd is going to change default behaviour for other people's processes.
They actually added the functionality over 5 years ago. Which is when the tmux project was approached to accept a patch to support pam (not systemd) in order to not be killed.
http://tmux-users.narkive.com/LXp72CHV/pam-support-in-tmux
All they did recently was try to change the default configuration to enable the feature by default.
> Shouldn't this code be part of glibc instead of tmux? -- Nicholas Marriott, 2011
> If you want to change how processes daemonize, why don't you change how daemon() is implemented [...] ? -- Nicholas Marriott, 2016
Systemd developer asks libc to add systemd specific code
This whole comment thread is about an optional feature that has existed for 5 years and only recently had its default value changed. You are not affected unless you are running a bleeding edge distribution that has already upgraded to a version of systemd released 5 days ago.
I don't think a more long term solution will present itself in the near future and most likely what will happen is that the default will get changed back to disabled.
nohup is not a hack
What systemd is offering has nothing to do with nohup, it's not "a flavour" of nohup it's a completely different thing
Systemd is not correctly killing processes, this was NEVER DONE LIKE THIS, they decided this out of a whim because apparently Gnome can't do the right thing (how surprising)
I'm not looking forward to what comes next when Gnome breaks through the new system.