You are not logged in.
Hello,
Has anyone else noticed that GNOME leaves leftover processes after a user logs out? There's a lot of them, like gnome-keyring-daemon, "dbus-daemon --session", goa-daemon, gnome-shell-calendar-server, gconfd-2, evolution-calendar-factory, etc. This becomes a problem when users continuously log in and log out, like is the case in my household where our children share a PC.
I don't recall this being an issue prior to the upgrade to GNOME 3.18.
What software component would be responsible for killing all these processes upon logout; gnome-session?
Cheers,
Eloy Paris.-
Offline
Yes, same on my machine. I noticed the leftovers with loginctl.
Offline
Perhaps it's not necessarily a change in GNOME doing it and instead systemd as when you look at the process list as a tree, those GNOME processes are all started by a "/usr/lib/systemd/systemd --user" process.
Offline
How do they log in? GDM?
Offline
How do they log in? GDM?
Yes, via GDM.
For now I set “KillUserProcesses=yes” in logind.conf.
Offline
Hello, I am an upstream D-Bus maintainer.
Short version: if you want users' background processes to be killed at the end of their login session, KillUserProcesses=yes is the right answer.
The Arch Linux maintainer of D-Bus has configured it to use the model where D-Bus session services are treated as per-user services. This means they are shared between multiple logins (if you log in once in X11, once in text mode and once via ssh, they all share the same evolution-calendar-factory), which means it would be inappropriate for them to be terminated at the end of the X11 login session. If you want them to be terminated when you have no more parallel login sessions, that's what KillUserProcesses=yes is there for.
In older dbus versions, or modern dbus versions configured the older way, there was an arbitrary distinction between background services like evolution-calendar-factory and goa-daemon that use D-Bus to communicate (they would terminate with the dbus-daemon, at the end of the X11 session), and background services like ssh-agent and gpg-agent that use non-D-Bus mechanisms to communicate (they would not normally terminate).
Even with KillUserProcesses=no, you should get no more than one instance of each service per user. For instance, if Alice logs in then logs out, Bob logs in then logs out, and Alice logs in again, there should only be one copy of goa-daemon running as Alice. If Alice gets a second copy of goa-daemon (or any other affected service), please report that as a bug.
Further details: https://bugs.freedesktop.org/show_bug.cgi?id=94508
I am an upstream (and Debian) developer. Not an Arch Linux user, no special knowledge of anything Arch-specific.
Offline
Is this related to the bug 47734:
https://bugs.archlinux.org/task/47734?s … &closedto=
Offline
@smcv -- Hi Simon, thanks for the insight and for taking the time to come here to comment. The rationale for leaving the processes running makes sense. I don't recall if I have seen more than one instance of each service per user but I'll keep an eye on it after changing KillUserProcesses back to 'no' (I've been running it with it set to 'yes' for a while). If there is a second copy of some affected process, what component should the bug be filed against; the affected service itself?
There is another (minor) issue at play here. No idea if it is related, though -- utmp (/var/run/utmp) keeps collecting logged in users. It's like if utmp records are not properly closed after a user logs out. One can see this by running the "w", "who -a", or "uptime" commands and looking at the number of logged in users after a system has been up for a while and users have been logging in and out. "who -a" shows that the terminals are not pseudo-terminals so the orphaned entries are from GDM sessions. Running "loginctl" does show the current number of existing, open sessions.
Cheers,
Eloy Paris.-
Offline
When you have a system in this state, please use systemd-cgls to list what is running within the context of a particular login session, and what is running outside login sessions; and use `loginctl` and `loginctl session-status` to list what logind thinks is going on. Please report this information here or on <https://github.com/systemd/systemd/issues/2900>. In particular, the State of each login session and the processes remaining in each login session are likely to be important.
It isn't clear from the original report precisely what is happening here, and systemd upstream would like to know what is going on.
Examples from a running (not-logged-out) Debian system where I am logged in via gdm and a tty:
% systemd-cgls
...
└─user.slice
├─user-1000.slice
│ ├─user@1000.service <- me, outside any particular session
│ │ ├─gvfs-daemon.service
...
│ │ ├─dbus.service
│ │ │ ├─2857 /usr/bin/dbus-daemon --session --address=systemd: --nofork --nopi
...
│ │ │ ├─4088 /usr/lib/gnome-terminal/gnome-terminal-server
│ │ │ ├─6248 zsh
│ │ │ ├─6535 systemd-cgls
│ │ │ └─6536 pager
...
│ ├─session-9.scope <- me, on the tty
│ │ ├─6077 /bin/login --
│ │ └─6087 -zsh
│ └─session-4.scope <- me, in X11 via gdm
│ ├─2798 gdm-session-worker [pam/gdm-password]
│ ├─2817 /usr/lib/gdm3/gdm-x-session --run-script default
│ ├─2819 /usr/lib/xorg/Xorg vt2 -displayfd 3 -auth /run/user/1000/gdm/...
│ ├─2831 /usr/lib/gnome-session/gnome-session-binary
...
└─user-119.slice <- the system user for gdm
├─session-c1.scope
│ ├─1383 gdm-session-worker [pam/gdm-launch-environment]
│ ├─1441 /usr/lib/xorg/Xorg vt7 -displayfd 3 -auth /run/user/119/gdm/...
│ ├─1575 /usr/lib/gnome-session/gnome-session-binary ...
...
└─user@119.service
├─dbus.service
│ ├─1610 /usr/bin/dbus-daemon --session --address=systemd: --nofork --nopi
│ ├─1621 /usr/lib/at-spi2-core/at-spi-bus-launcher
│ ├─1626 /usr/bin/dbus-daemon --config-file=/etc/at-spi2/accessibility.con
│ └─1629 /usr/lib/at-spi2-core/at-spi2-registryd --use-gnome-session
└─init.scope
├─1426 /lib/systemd/systemd --user
└─1429 (sd-pam)
% loginctl
SESSION UID USER SEAT
4 1000 smcv seat0
9 1000 smcv seat0
c1 119 Debian-gdm seat0
% loginctl session-status 4
4 - smcv (1000)
...
Seat: seat0; vc2
TTY: /dev/tty2
Service: gdm-password; type x11; class user
State: active
Unit: session-4.scope
├─2798 gdm-session-worker [pam/gdm-password]
...
% loginctl session-status 9
9 - smcv (1000)
Since: Mon 2016-04-11 13:02:08 BST; 6min ago
Leader: 6077 (login)
Seat: seat0; vc5
TTY: /dev/tty5
Service: login; type tty; class user
State: online
Unit: session-9.scope
├─6077 /bin/login --
└─6087 -zsh
I am an upstream (and Debian) developer. Not an Arch Linux user, no special knowledge of anything Arch-specific.
Offline
If there is a second copy of some affected process, what component should the bug be filed against; the affected service itself?
I think that makes sense, at least initially. If your bug reporting process collects extra information about the component you're filing a bug against (version number, etc.) like Debian's reportbug tool does, then it would probably be useful to make sure you include that information for dbus and systemd.
utmp (/var/run/utmp) keeps collecting logged in users. It's like if utmp records are not properly closed after a user logs out.
Sorry, I don't know the finer details of how utmp works. You might have a utmp record for each user whose `systemd --user` is still running, perhaps? If you do, then that would be another symptom of their session having not really ended.
Running "loginctl" does show the current number of existing, open sessions.
Does it additionally show any non-open sessions, perhaps in state "closing"?
I am an upstream (and Debian) developer. Not an Arch Linux user, no special knowledge of anything Arch-specific.
Offline