Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
smcv opened this Issue Mar 25, 2016 · 8 comments

Comments

4 participants
@smcv
Copy link
Contributor

smcv commented Mar 25, 2016

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

This comment has been minimized.

Copy link
Contributor Author

smcv commented Mar 25, 2016

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.

@poettering

This comment has been minimized.

Copy link
Member

poettering commented Apr 1, 2016

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 added a commit to keszybz/systemd that referenced this issue Apr 10, 2016

logind: flip KillUserProcesses to on by default
This ensures that users sessions are properly cleaned up after.
The admin can still enable or disable linger for specific users to allow
them to run processes after they log out. Doing that through the user
session is much cleaner and provides better control.

dbus daemon can now be run in the user session (with --enable-user-session,
added in 1.10.2), and most distributions opted to pick this configuration.
In the normal case it makes a lot of sense to kill remaining processes.
The exception is stuff like screen and tmux. But it's easy enough to
work around, a simple example was added to the man page in previous
commit. In the long run those services should integrate with the systemd
users session on their own.

https://bugs.freedesktop.org/show_bug.cgi?id=94508
systemd#2900

keszybz added a commit to keszybz/systemd that referenced this issue Apr 10, 2016

logind: flip KillUserProcesses to on by default
This ensures that users sessions are properly cleaned up after.
The admin can still enable or disable linger for specific users to allow
them to run processes after they log out. Doing that through the user
session is much cleaner and provides better control.

dbus daemon can now be run in the user session (with --enable-user-session,
added in 1.10.2), and most distributions opted to pick this configuration.
In the normal case it makes a lot of sense to kill remaining processes.
The exception is stuff like screen and tmux. But it's easy enough to
work around, a simple example was added to the man page in previous
commit. In the long run those services should integrate with the systemd
users session on their own.

https://bugs.freedesktop.org/show_bug.cgi?id=94508
systemd#2900

keszybz added a commit to keszybz/systemd that referenced this issue Apr 10, 2016

logind: flip KillUserProcesses to on by default
This ensures that users sessions are properly cleaned up after.
The admin can still enable or disable linger for specific users to allow
them to run processes after they log out. Doing that through the user
session is much cleaner and provides better control.

dbus daemon can now be run in the user session (with --enable-user-session,
added in 1.10.2), and most distributions opted to pick this configuration.
In the normal case it makes a lot of sense to kill remaining processes.
The exception is stuff like screen and tmux. But it's easy enough to
work around, a simple example was added to the man page in previous
commit. In the long run those services should integrate with the systemd
users session on their own.

https://bugs.freedesktop.org/show_bug.cgi?id=94508
systemd#2900

keszybz added a commit to keszybz/systemd that referenced this issue Apr 10, 2016

logind: flip KillUserProcesses to on by default
This ensures that users sessions are properly cleaned up after.
The admin can still enable or disable linger for specific users to allow
them to run processes after they log out. Doing that through the user
session is much cleaner and provides better control.

dbus daemon can now be run in the user session (with --enable-user-session,
added in 1.10.2), and most distributions opted to pick this configuration.
In the normal case it makes a lot of sense to kill remaining processes.
The exception is stuff like screen and tmux. But it's easy enough to
work around, a simple example was added to the man page in previous
commit. In the long run those services should integrate with the systemd
users session on their own.

https://bugs.freedesktop.org/show_bug.cgi?id=94508
systemd#2900
@keszybz

This comment has been minimized.

Copy link
Member

keszybz commented Apr 11, 2016

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 keszybz closed this Apr 11, 2016

@smcv

This comment has been minimized.

Copy link
Contributor Author

smcv commented Apr 11, 2016

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

This comment has been minimized.

Copy link
Member

keszybz commented Apr 12, 2016

Oops, wrong button.

@keszybz keszybz reopened this Apr 12, 2016

keszybz added a commit to keszybz/systemd that referenced this issue Apr 13, 2016

logind: flip KillUserProcesses to on by default
This ensures that users sessions are properly cleaned up after.
The admin can still enable or disable linger for specific users to allow
them to run processes after they log out. Doing that through the user
session is much cleaner and provides better control.

dbus daemon can now be run in the user session (with --enable-user-session,
added in 1.10.2), and most distributions opted to pick this configuration.
In the normal case it makes a lot of sense to kill remaining processes.
The exception is stuff like screen and tmux. But it's easy enough to
work around, a simple example was added to the man page in previous
commit. In the long run those services should integrate with the systemd
users session on their own.

https://bugs.freedesktop.org/show_bug.cgi?id=94508
systemd#2900

@poettering poettering added the RFE 🎁 label Apr 15, 2016

@pacho2

This comment has been minimized.

Copy link

pacho2 commented Apr 15, 2016

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

keszybz added a commit to keszybz/systemd that referenced this issue Apr 15, 2016

logind: flip KillUserProcesses to on by default
This ensures that users sessions are properly cleaned up after.
The admin can still enable or disable linger for specific users to allow
them to run processes after they log out. Doing that through the user
session is much cleaner and provides better control.

dbus daemon can now be run in the user session (with --enable-user-session,
added in 1.10.2), and most distributions opted to pick this configuration.
In the normal case it makes a lot of sense to kill remaining processes.
The exception is stuff like screen and tmux. But it's easy enough to
work around, a simple example was added to the man page in previous
commit. In the long run those services should integrate with the systemd
users session on their own.

https://bugs.freedesktop.org/show_bug.cgi?id=94508
systemd#2900

keszybz added a commit to keszybz/systemd that referenced this issue Apr 21, 2016

logind: flip KillUserProcesses to on by default
This ensures that users sessions are properly cleaned up after.
The admin can still enable or disable linger for specific users to allow
them to run processes after they log out. Doing that through the user
session is much cleaner and provides better control.

dbus daemon can now be run in the user session (with --enable-user-session,
added in 1.10.2), and most distributions opted to pick this configuration.
In the normal case it makes a lot of sense to kill remaining processes.
The exception is stuff like screen and tmux. But it's easy enough to
work around, a simple example was added to the man page in previous
commit. In the long run those services should integrate with the systemd
users session on their own.

https://bugs.freedesktop.org/show_bug.cgi?id=94508
systemd#2900

keszybz added a commit to keszybz/systemd that referenced this issue Apr 21, 2016

logind: flip KillUserProcesses to on by default
This ensures that users sessions are properly cleaned up after.
The admin can still enable or disable linger for specific users to allow
them to run processes after they log out. Doing that through the user
session is much cleaner and provides better control.

dbus daemon can now be run in the user session (with --enable-user-session,
added in 1.10.2), and most distributions opted to pick this configuration.
In the normal case it makes a lot of sense to kill remaining processes.
The exception is stuff like screen and tmux. But it's easy enough to
work around, a simple example was added to the man page in previous
commit. In the long run those services should integrate with the systemd
users session on their own.

https://bugs.freedesktop.org/show_bug.cgi?id=94508
systemd#2900
@pacho2

This comment has been minimized.

Copy link

pacho2 commented Feb 17, 2017

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!

dm0- added a commit to dm0-/systemd that referenced this issue Oct 30, 2018

Merge pull request systemd#2900 from dm0-/rust
Upgrade Rust to 1.21.0
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.