On Tumbleweed (current) and I’m using x2go to start a session which invokes /usr/bin/startplasma-x11. When I “logout” from KDE, a lot of left over processes stay around:
I’m AD joined and interactive users get a Kerberos ticket. I’ve noticed that my account in AD gets locked out a lot, and wondered if it’s possibly because of these derelict processes and that kerberos ticket renewals still don’t work properly.
All of this used to work reasonably well as long as I didn’t stay logged in beyond ticket expiration (or possibly renew expiration). So, in the past, as long as I logged out, everything was “fine”. But now, my account gets locked even if I’m “logged out”.
I haven’t done enough long term testing to verify if I nuke those extraneous processes if that fixes the lockout issue or not, but I think it does.
It has been this way for a long time – probably since Plasma5 showed up.
The first process that you show – that “systemd” process – seems to be the key. If you kill that, then most of the others will go away.
I’m not sure, but I think this is part of how “systemd” works. When you logout, that “systemd” user process hangs around for a while. I think it times out a few minutes later, and possibly it ends when a different user logs in.
I don’t know if this is related to your kerberos issues.
They are not leftover - they are user services started by systemd user instance. User instance is launched with the first login session and remains running until the last session terminates. So the first obvious thing to check - do you have other login sessions for the same user?
None. The “session” started by /usr/bin/startplasma-x11 is terminated. The processes shown are all that is left for that user, parented by the systemd --usermostly, but also the “init” owned baloo_file and geoclue agent.
$ grep Kill /etc/systemd/logind.conf
#KillUserProcesses=no
#KillOnlyUsers=
#KillExcludeUsers=root
$ man logind.conf | grep -A 3 Kill
KillUserProcesses=
Takes a boolean argument. Configures whether the processes of a user should be killed when the user logs out. If true, the scope unit corresponding to the session and
all processes inside that scope will be terminated. If false, the scope is "abandoned", see systemd.scope(5), and processes are not killed. Defaults to "no", but see
the options KillOnlyUsers= and KillExcludeUsers= below.
In addition to session processes, user process may run under the user manager unit user@.service. Depending on the linger settings, this may allow users to run
processes independent of their login sessions. See the description of enable-linger in loginctl(1).
TL;DR it’s a mess, no good solution. But LP says maybe KillUserProcesses should default to yes (noting it breaks other things like suspended session sorts of things… sigh).
Edit: btw, it doesn’t work. Processes remain.
Linux has become boring. “World, I present to you: systemd”
This command does not start any login session. To execute this command you must already have logged in and this login started session and systemd user instance.
erlangen:~ # systemd-cgls /sys/fs/cgroup/user.slice/user-1005.slice/
Directory /sys/fs/cgroup/user.slice/user-1005.slice/:
Failed to list cgroup tree: No such file or directory
erlangen:~ #
I remember the days when users logged out and left behind zombies consuming 100% time of the single CPU. System administrators told the users still logged in that only a reboot would kill the zombies.
Nowadays a user can log into multiple sessions. Upon logout all child processes are reliably terminated. You may read some fine documentation man loginctl. See also systemd/User - ArchWiki.