systemd --user: start a new systemd.special(7) target when we have no more login-sessions

[smcv]

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 user@1000.service 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".

[smcv]

I don't particularly want the per-user dbus.service to declare that conflict or otherwise terminate on logout unless killed by KillUserProcesses

However, system integrators could easily give dbus (or any other user service) Conflicts=logout.target as a vendor customization via a .d drop-in, if they are particularly attached to the old behaviour.

[smcv]

I don't particularly want the per-user dbus.service to declare that conflict or otherwise terminate on logout unless killed by KillUserProcesses

However, system integrators could easily give dbus (or any other user service) Conflicts=logout.target as a vendor customization via a .d drop-in, if they are particularly attached to the old behaviour.

[smcv]

References: https://bugs.freedesktop.org/show_bug.cgi?id=94508, https://bugzilla.gnome.org/show_bug.cgi?id=764146, https://bugs.gentoo.org/show_bug.cgi?id=577416, https://bbs.archlinux.org/viewtopic.php?id=204307

[smcv]

References: https://bugs.freedesktop.org/show_bug.cgi?id=94508, https://bugzilla.gnome.org/show_bug.cgi?id=764146, https://bugs.gentoo.org/show_bug.cgi?id=577416, https://bbs.archlinux.org/viewtopic.php?id=204307

[poettering]

I am not sure I follow. Note that user@.service is already reference counted by the login sessions around. i.e. it is started before the first user session of a specific user is created, and stopped when the last user session ends. I don't follow why that behaviour is not sufficient?

[poettering]

I am not sure I follow. Note that user@.service is already reference counted by the login sessions around. i.e. it is started before the first user session of a specific user is created, and stopped when the last user session ends. I don't follow why that behaviour is not sufficient?

[keszybz]

user@.service does not exit after the last login if lingering is enabled. And lingering might be needed for other reasons. So this RFE is about having a simple way to terminate services that should only run during a live session.

After reading the PR, my first thought was that services should watch the number of concurrent logins themselves. This certainly can be done using sd_login_monitor, or directly using dbus. But I think we need an even simpler approach. I buy the argument that this logic is not something that we want to be reimplemented in every little user service and script.

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.

Yeah, that'd work. Maybe we'd want to call that last-logout.target to make it even more explicit.

[keszybz]

user@.service does not exit after the last login if lingering is enabled. And lingering might be needed for other reasons. So this RFE is about having a simple way to terminate services that should only run during a live session.

After reading the PR, my first thought was that services should watch the number of concurrent logins themselves. This certainly can be done using sd_login_monitor, or directly using dbus. But I think we need an even simpler approach. I buy the argument that this logic is not something that we want to be reimplemented in every little user service and script.

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.

Yeah, that'd work. Maybe we'd want to call that last-logout.target to make it even more explicit.

[smcv]

Note that user@.service is already reference counted by the login sessions around. i.e. it is started before the first user session of a specific user is created, and stopped when the last user session ends. I don't follow why that behaviour is not sufficient?

I never experienced the same issue as the downstream reporters myself (see downstream bug references above). I've asked them for more information to try to determine what's going on: whether the login-sessions are not ending because they contain surviving process ("closing" state), or whether the user-session is lingering, or what.

Maybe we'd want to call that last-logout.target to make it even more explicit.

Sure, that sounds like a better name. I'm happy for the bike shed to be any colour as long as it keeps the rain off the bikes :-)

Is there a reason why this is already closed? Your comment doesn't sound as though this is either "won't fix" or already implemented?

[smcv]

Note that user@.service is already reference counted by the login sessions around. i.e. it is started before the first user session of a specific user is created, and stopped when the last user session ends. I don't follow why that behaviour is not sufficient?

I never experienced the same issue as the downstream reporters myself (see downstream bug references above). I've asked them for more information to try to determine what's going on: whether the login-sessions are not ending because they contain surviving process ("closing" state), or whether the user-session is lingering, or what.

Maybe we'd want to call that last-logout.target to make it even more explicit.

Sure, that sounds like a better name. I'm happy for the bike shed to be any colour as long as it keeps the rain off the bikes :-)

Is there a reason why this is already closed? Your comment doesn't sound as though this is either "won't fix" or already implemented?

[keszybz]

Oops, wrong button.

[keszybz]

Oops, wrong button.

[pacho2]

I have replied to the question at:
https://bugs.freedesktop.org/show_bug.cgi?id=94508#c7

In summary, in the attachment we uploaded to Gentoo bugzilla, https://577416.bugs.gentoo.org/attachment.cgi?id=428490 ,you can see the systemd-cgls output just after logging out from a Gnome 3.18 session. With user-session disabled (or dbus-1.8) all processes end up dying after logout, but with user-session enabled, they (gvfs, pulseaudio, tracker, dconf, goa, evolution-*, mission-control...) are left running forever

Thanks

[pacho2]

I have replied to the question at:
https://bugs.freedesktop.org/show_bug.cgi?id=94508#c7

In summary, in the attachment we uploaded to Gentoo bugzilla, https://577416.bugs.gentoo.org/attachment.cgi?id=428490 ,you can see the systemd-cgls output just after logging out from a Gnome 3.18 session. With user-session disabled (or dbus-1.8) all processes end up dying after logout, but with user-session enabled, they (gvfs, pulseaudio, tracker, dconf, goa, evolution-*, mission-control...) are left running forever

Thanks

[pacho2]

I have seen some distributions are "reverting" the KillUserProcess default to "no" to not break tmux, screen... I have seen there is already an option to exclude full users from getting their processes killed... but I am not sure if it would be possible to also being able to exclude concrete processes names from being killed too :/

That would allow people to list there daemons and things like tmux, screen and still kill all the other processes :|

Thanks!

[pacho2]

I have seen some distributions are "reverting" the KillUserProcess default to "no" to not break tmux, screen... I have seen there is already an option to exclude full users from getting their processes killed... but I am not sure if it would be possible to also being able to exclude concrete processes names from being killed too :/

That would allow people to list there daemons and things like tmux, screen and still kill all the other processes :|

Thanks!