Submission type

• Request for enhancement (RFE)

systemd version the issue has been seen with

229

Used distribution

any (original reports were on Arch and Gentoo)

RFE

With the traditional X11-login-session-centric setup for D-Bus, terminating a GUI session would terminate the X server, resulting in dbus-launch being disconnected. dbus-launch kills the session dbus-daemon, and all (well-behaved) session services exit.

With the move to an optional user-session-centric D-Bus setup, the transition from 1 to 0 parallel login sessions no longer terminates services like evolution-data-server. Similarly, systemd user services that do not communicate via D-Bus (for example gpg-agent, ssh-agent) will not terminate until the systemd --user started by system unit [email protected] kills them.

This can be addressed system-wide by using KillUserProcesses=yes, but that's quite a big hammer: it terminates //all// user services, including things like screen(1) which users might prefer not to terminate, and it is done as a mandatory thing at system level rather than voluntarily at user level.

My suggestion is to add a new user systemd.special(7) target, perhaps logout.target, which would be started by systemd --user when it detects the transition from 1 to 0 parallel login sessions. Services that want to voluntarily terminate at this point would declare Conflicts=logout.target.

I don't particularly want the per-user dbus.service to declare that conflict or otherwise terminate on logout unless killed by KillUserProcesses, because I don't think there should be an arbitrary distinction between the user-services that happen to use D-Bus to communicate and the user-services that don't. However, I'm open to persuasion on this point if the kdbus developers do intend to reap the kdbus socket at the transition from 1 to 0 login sessions. I think it makes sense for dbus-daemon's systemd --user integration to resemble what kdbus is intended to look like: I see its role as "this is the next best thing if we can't have kdbus yet".