It seems that every systemd-related discussion is bound to be filled with all kinds of arguments, but completely devoid of discussion about the actual problem b

It seems that every systemd-related discussion is bound to be filled with all kinds of arguments, but completely devoid of discussion about the actual problem being solved. I can see how the "take no prisioners" attitude from systemd developers encourages this, but it doesn't lead anywhere. In this case, the management of user processes is a real problem. It's very easy to accumulate lots of forgotten processes on shared machines with long uptimes. Think ad-hoc scripting servers and jumpboxes here. Think nohup'ed perl scripts that hung waiting for something that'll never happen. When you run "screen" or "tmux" you expect them to survive a broken session (i.e. you expect them to behave like an independent session). However, when you run something under "nohup" you mostly expect it to survive the controlling terminal going away (a particular screen window or SSH connection being killed). You may be okay with it being killed if you no longer have a session to the server. A user process running in the background without a controlling terminal isn't a service, and from my experience most users don't expect it to be. There is a subtle difference between a "session" and a "connection" that's not properly implemented without systemd (and can be argued not to be properly implemented _with_ systemd). The thing is how to implement this without "screen" or "tmux" explicitly informing systemd that they want a new session. Touching any API that's used beyond terminal multiplexers defeats the whole purpose.