What breakage does this actually fix?

On the (single user) desktop, I don't see much of a problem with this idea.

On servers, cluster nodes in a scientific environment, shared desktops, etc. I'd expect this to be disabled by default. With Linux that is the majority of use-cases, as single user linux-desktop is a small niche of the whole spectrum I guess...

The whole thing appears to be in the hands of distributors. Systemd is a raw tool (like a swiss army knife with a BFG 9000 included ;-) and they need to expose only the safe parts for normal use and include some safety precautions for the BFG.

If all distro's have to put in work to make every new systemd release palatable it should become an upstream problem to reduce the redundant work in all distro's.

> (or something, I don't really understand systemd).

Remember how it was common in Gnome 2-land to have a session manager process? So you could go into there and say 'I want FOO started when I log in'?. People would use it for all sorts of fun things. Starting up browsers, launching their terminals, blocking daemons they didn't want launched.

Then along came XDG and the various *.desktop things to make app menus cross-platform. So you could put *.desktop files in ~/.config/autostart/ and have them autostart when you logged into X (provided you used a desktop environment that was compliant).

Systemd wants to do that same sort of thing for your user, but have it be system-wide. That is one of the reasons they want Kdbus.. so you wouldn't have to run all the dbus-launch stuff for each login. You could have a dbus for a user account and have it 'just work'. Thus you have 'user sessions'.

So a lot of the commands you use for managing the init system for your system can be used to manage your user session for your user by using the '--user' option.

So for example I have a ~/.config/systemd/user/synergys.service on my desktop. When I start up my laptop I have a corresponding synergyc service that launches and they try to talk over a ssh session. I can automate the management of all of this through systemd and '--user'.

systemctl enable --user synergys

systemctl start --user synergys

systemctl status --user synergys

journalctl --user -f

etc etc. These things work as expected, but just for your user account.

Thanks for highlighting that. The freedesktop bug is really illuminating, and I wish that people would read it, in full, and understand it before they fly off the handle blaming 'GNOME'... sigh!

In what usecase is it an actual problem? In a single user desktop/laptop setting I presume you shutdown the system after logout (why else would you logout?), so the process gets killed anyway. In a multiuser server setting the system administrator will notice that there's a rogue process using 100% CPU and will kill that process (preferably after contacting the user and ensuring that the process in questions is rogue indeed and something actually making overnight calculation or something like that). The system administrator has to watch out of these kind of processes even if users are logged in anyway. I do think it's the small minority case where this feature could be useful. As far as I understood the article, 3 distributions out of the 3 that made a decision on this feature, disabled the feature, so the default should be the disabling in upstream too.

As to the technical choice that every program who wants to avoid getting killed after logout has to link against libsystemd - throwing out binary compatibility again. They could have provided some kind of wrapper, so screen could be aliased to something like "wrapper screen".