For some days I am suffering an strange behavior: when I logout, lots of processes from the gnome session are kept running. This causes problems when other users try to login in their accounts. Googling a bit, I saw the same problem on Arch: https://bbs.archlinux.org/viewtopic.php?id=204307 And I have seen that this is caused by dbus-1.10.x upgrade, if I switch back 1.8.x releases all go back to normal and processes die when logging out. I am running systemd-228 that, supposedly, it should play well with dbus-1.10 and the --enable-user-session change :/ Thanks a lot for your help :)
Can you elaborate on exactly what kind of problems these leftover processes cause?
Apart of ending up with tons of processes from every user that has logged in, you can have random issues like, for example, gnome keyring misbehaving (password missing for example)
Are the leftover processes part of a logind session, or are they children of the systemd --user instance? The latter should be cleaned up once all logind sessions for the user have been ended.
You can use the systemd-cgls program to see where the processes fall in the systemd cgroup hierarchy. logind sessions will appear as "session-xxx.scope".
Created attachment 428314 [details] output Looks like some are in the session group while others not :/ The attached file shows the output once I have logged out and, that way, you will see all the leftover processes (I am user 1001 there)
Ok, so I would start with gdm-session-worker, and see if we can figure out why that process is hanging around in all of your sessions.
Err, I guess that's user 101. For user 1001, you appear to have an instance of deluged running in the background that is probably holding the session open.
(In reply to Mike Gilbert from comment #7) > Err, I guess that's user 101. > > For user 1001, you appear to have an instance of deluged running in the > background that is probably holding the session open. It's normal that deluged keeps running, it has always behaved that way to keep downloading things and, with dbus-1.8, it wasn't preventing all the other processes for dying as soon as X exited. Also, this same is happening to many other users in other machines that don't run deluge. Regarding gdm-session-worker... do you think our pam files are ok? I have no idea about PAM... but that is something we carry downstream as they differ between all distributions and maybe it's prone to contain some errors :/ $ cat /etc/pam.d/gdm-launch-environment account required pam_nologin.so account required pam_succeed_if.so audit quiet_success user = gdm account required pam_permit.so auth required pam_env.so auth required pam_succeed_if.so audit quiet_success user = gdm auth required pam_permit.so password required pam_deny.so -session optional pam_systemd.so kill-session-processes=1 session optional pam_keyinit.so force revoke session required pam_succeed_if.so audit quiet_success user = gdm session required pam_permit.so
(In reply to Pacho Ramos from comment #8) > It's normal that deluged keeps running, it has always behaved that way to > keep downloading things and, with dbus-1.8, it wasn't preventing all the > other processes for dying as soon as X exited. Which other processes are you referring to? It is normal for the processes in user@1001.scope to keep running until all sessions have been closed. I think deluged is keeping your session open. If you have linger enabled for the user in question, they may keep running until the system reboots. With dbus-1.8, these dbus-actived processes would probably be killed when dbus-daemon dies due to losing its DISPLAY; with dbus-1.10, dbus-daemon is not tied to an X11 DISPLAY, so it does not get killed when X gets killed. As for the other processes in session-13.scope: I am unfamiliar with ibus, so I don't know how it is supposed to behave.
(In reply to Mike Gilbert from comment #9) > It is normal for the processes in user@1001.scope to keep running until all > sessions have been closed. Sorry, this should say user@1001.service, not user@1001.scope.
Other processes like pulseaudio, gconf, all the evolution subprocesses, gvfs, ibus... :/
Created attachment 428490 [details] output This is the output on a different system, in this case with no deluge at all (a system that, with dbus-1.8, was leaving 0 processes behind when logging out)
All works properly (i.e, all leftover processes die) if I manually kill the dbus-daemon that is supposedly launched by system, I mean, the one that runs with this options: pacho 1794 1.3 0.1 32424 4128 ? Ss 12:28 0:00 /usr/bin/dbus-daemon --session --address=systemd: --nofork --nopidfile --systemd-activation
(In reply to Pacho Ramos from comment #13) > All works properly (i.e, all leftover processes die) if I manually kill the > dbus-daemon that is supposedly launched by system, I mean, the one that runs > with this options: > pacho 1794 1.3 0.1 32424 4128 ? Ss 12:28 0:00 > /usr/bin/dbus-daemon --session --address=systemd: --nofork --nopidfile > --systemd-activation Right, so the other processes are killed by accident when their bus connection is terminated. I think this is just a difference in how dbus user-sessions are designed; dbus is no longer tied to a single login session. For what it's worth, I don't have this problem with KDE 5; it seems to properly terminate all processes in my login session, which causes systemd --user and its children to terminate when it is no longer neeed. I think the bug here is in GNOME and/or ibus.
I did a little playing around, and the behavior is little different than what I was guessing. Random processes like deluged will not keep the session open. I'm honestly not quite sure what is happening with GNOME. I'll have to look into what actually causes user@%i.service to stop.
I have just reported to gnome-session upstream (gnome-session should take care of handling the logout process), hopefully they will give some light (as dbus upstream is still quiet :S) https://bugzilla.gnome.org/show_bug.cgi?id=764146
As I see in: https://bugs.freedesktop.org/show_bug.cgi?id=94508 https://bugzilla.gnome.org/show_bug.cgi?id=764146 It seems that we should probably hard disable user-sessions as it seems we need to make more changes to properly support it... anyway I will still wait for more replies and information in upstream report (action is now taking care in the dbus bug... for the case you want to follow it :))
Ah, and from "systemd" point of view, maybe this feature request also serves as a good summary :) https://github.com/systemd/systemd/issues/2900
(In reply to Pacho Ramos from comment #17) > It seems that we should probably hard disable user-sessions as it seems we > need to make more changes to properly support it... Let's add a USE flag for it; it works well enough for some use cases. I would say we disable it by default, and allow users to opt-in. If we want to enable it in specific profiles (like plasma/systemd) that's another option I will leave to the relevant maintainers.
I added a "user-session" USE flag to 1.10.8-r1. Please give it a shot. If that works for you, I guess the same change can be applied to 1.10.6, which has been stabilized on amd64 (again). https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=268ebcded3db897d3cc8a5fe860c453503f8304c
Thanks, I will try as soon as possible. Anyway, looking to bug 577842 I would disable it completely for now as the way it breaks reverse deps is a bit "unpredictable", I mean, it's hard to know a reverse dep will break at *runtime* and also, looking that this problems are still present and randomly appearing for so many months that some distributions are shipping this, makes me thing this is not mature enough :/ Other options could be to: - rely on having it use.masked by default - Show a warning when the USE flag is enabled to hint the users about the kind of problems they could suffer (this would be my preferred option as a compromise for letting people to test this setup but ensure they know the consequences). My main point is to prevent issues like cairo[xlib-xcb] (bug #508232), that causes people to hit some random bugs and being a bit hard to remember that they care caused by that (I remember a libreoffice presentation bug that was a bit unintuitive to think about cairo[xlib-xcb] being the culprit)
Also, last time I checked, kdbus was being entirely redone, then, I am not sure if testing this way of launching dbus-daemon will really help as it's (again) a bit unpredictable what will finally happen on that side :/
[master 357fcd2] sys-apps/dbus: Warn people about the potential breakages they could get when enabling user-session (#577416#c21) 1 file changed, 12 insertions(+)
(In reply to Mike Gilbert from comment #20) > I added a "user-session" USE flag to 1.10.8-r1. Please give it a shot. > > If that works for you, I guess the same change can be applied to 1.10.6, > which has been stabilized on amd64 (again). > > https://gitweb.gentoo.org/repo/gentoo.git/commit/ > ?id=268ebcded3db897d3cc8a5fe860c453503f8304c It works fine, but I would stabilize 1.10.8-r1 directly instead of backporting to 1.10.6
(In reply to Pacho Ramos from comment #24) > It works fine, but I would stabilize 1.10.8-r1 directly instead of > backporting to 1.10.6 That should be fine; 1.10.8 has been in the tree ~26 days, so you can probably go ahead and create that stablereq.
done, it's bug 578946 ;)
*** Bug 577160 has been marked as a duplicate of this bug. ***
(In reply to Pacho Ramos from comment #18) > Ah, and from "systemd" point of view, maybe this feature request also serves > as a good summary :) > https://github.com/systemd/systemd/issues/2900
(In reply to Pacho Ramos from comment #18) > Ah, and from "systemd" point of view, maybe this feature request also serves > as a good summary :) > https://github.com/systemd/systemd/issues/2900 This lead to the switch of KillUserProcesses= to yes by default in upstream side... but this was reverted downstream to not break screen, tmux... hence, this is still a problem for us :/
Can we assume this fixed as of 3.24.2?
I am unsure if all fixes were incorporated to 3.24: https://bugzilla.gnome.org/show_bug.cgi?id=764029#c35
Fixed as of 3.30 probably?
