It's not "platform specific code", it's breaking historical behaviour.
Killing user processes after logout (when they have been set to not do so, through nohup usually) is not sensible.
Edit: clarification
Killing user processes after logout (when they have been set to not do so, through nohup usually) is not sensible.
Edit: clarification
In other words, if this functionality had been added 21 years ago as well, a lot of mess and confusion would have been avoided and we'd all be happier, but since it didn't the systemd guys are trying to implement it retroactively, which is going to break a lot more stuff than tmux/screen/etc.
Only if you can succesfully determine which ones the user wants to keep running. Otherwise it's just breaking stuff, as this story shows.
if this functionality had been added 21 years ago as well, a lot of mess and confusion would have been avoided
Not really. You will always have sub-standard software that doesn't adhere to the system's declared semantics, and just goes by "what works" (ask the WineHQ guys). Any API that has been around for 21 years will have corner cases where software just breaks. That does not mean you're then free to break the old API yourself.
edit: If you're already using a specific command to tell the application to stay alive (e.g. nohup), you can use the "new" systemd command as well. nohup never related to a "session" scope because that didn't really exist before systemd. A new command _does_ break historical behaviour, but thanks god we do that from time to time. That's how innovation works.
How is it so? I cannot see a single legitimate justification for such a stupid behaviour.
> "session" scope
Exactly. There is no such a thing, and it should not exist, it's a totally alien concept to anything Unix.
(By the way, I disagree with this request to change tmux)
Not after "logout", but after terminal is detached. For whatever reason. There is no such a thing as "logout".
When I log off (by giving the logout command) the shell will print ‘logout’ and
execute commands from the file ‘.logout’ if it exists in my home directory. After
that the shell will terminate and UNIX will log me off the system.
The concept is commonly called logout, even if you prefer to call it something else.
If you had two logged-in terminals on your desk and ran 'logout' on one of them, are you still logged in?
Dbus devs apparently asked themselves the same, added the concept of a user session to dbus alongside the existing login session.
Gnome code happens to get the two confused (or dbus fails to properly tell one form the other, likely by mixing old and new behavior).
Systemd dev notices leftover Gnome processes, and convince Poettering to flip the safety on the big gun.
All this while giving crap all about unix conventions...
What you are describing is systemd becoming a kernel sitting on top of a kernel, second guessing the actual kernel.
... with nohup. Which now doesn't work.
(Added:) The first runtime, in systemd parlance (I think), would be the session scope, the second runtime would be the user service and the third... well, something different, as you'd pass on things (group memberships, environment variables, namespaces) from your shell/session into a long-lasting service. One probably would want to extend the "once the last of my session has ended" state to the runtime of the "run forever" command.
Most non-technical users, I guess, would really prefer one of the first two lifetimes to be the default. As being able to start from a clean state after logging in- and out is rather convenient.
As nohup, in an interactive shell, is used for the third "keep running forever" option, I think it would be reasonable for distributions to alias it to the relevant "systemd-run..." command for all default shells. Then user-expectations would be perfectly met (and scripts will still run the binary /usr/bin/nohup).
Progress is building upon the best practices of the past, not breaking things because a bunch of very low quality, uneducated "developers" who all came from an alien culture simply could not think of a better, idiomatic solution.
This is the level of discourse I've come to expect from any discussion related to systemd
> and no, unix signals are not a sane API
It might not be modern, but it's stable, widely used, and incredibly well documented. Hell, systemd is implementing this behavior using signals.
> Breaking with historical behavior is called progress.
It's not historical behavior when applications are today being developed that rely on said behavior.
I think the problem people have is that systemd developers seem to actually believe this axiom.