If I start a session with one user, do some activity and then close the session, and then I start a new session with a different user, I can see, in htop, several instances of the process "agent" that belong to the former user, and which path is /usr/libexec/geoclue-2.0/demos/. By the name I guess it has to do with geolocation, which I have not activated for that user (not sure if for any), so I guess it must come active by default. I don't think that's a nice privacy policy even in Linux and KDE dont have backdoors. Ok, let's center and not divagate too much... The point is that I believe that one user's processes should be shut down, or killed if they refuse to terminate gracefully, once the user logs out. There have been similar reports even since 10 years ago, but I'm not sure if those are exactly like this one. In one, it seemed related to encryption or Akonadi; in the other, affected the login process; this one I report doesnt seem to produce any malfunction in anything (the processes just "sit" there wasting resources). but if you consider this is a duplicate, feel free to mark it as such, but then please reopen the one that says it's resolved/fixed. The mentioned reports are these: https://bugs.kde.org/show_bug.cgi?id=244250 https://bugs.kde.org/show_bug.cgi?id=348123 Gentoo pure 64 bits (no multilib), KF 5.67, Plasma 5.18.1.
can I see output of your "loginctl show-session"
(In reply to David Edmundson from comment #1) > can I see output of your > > "loginctl show-session" Sorry, I'm on Gentoo, using OpenRC instead of Systemd, and I'm afraid I don't know of an equivalent command for loginctl. Can you suggest one?
Ok, forget about the former comment. I found it on Gentoo's fora. # ck-list-sessions Session2: unix-user = '1004' realname = '(null)' seat = 'Seat1' session-type = 'unspecified' session-class = 'user' session-state = 'active' active = TRUE x11-display = ':0' x11-display-device = '/dev/tty7' display-device = '' remote-host-name = '' is-local = TRUE on-since = '2020-02-19T15:06:53.014753Z' login-session-id = '2' XDG_RUNTIME_DIR = '/var/run/user/1004' VTNr = '7'
Hi. I wanted to add some info. I didn't know that Consolekit was deprecated nor that Elogind could be used in non systemd systems, but since now Im aware of it, I uninstaled CK and are now using Elogind. So, here you have the exact info that you asked (don't think it's necessary to run it as root, but just in case doing it as a "foot user" some info were missing): # loginctl show-session EnableWallMessages=no KillUserProcesses=no RebootToFirmwareSetup=no IdleHint=no IdleSinceHint=0 IdleSinceHintMonotonic=0 BlockInhibited=handle-power-key:handle-suspend-key:handle-hibernate-key:handle-lid-switch DelayInhibited=sleep InhibitDelayMaxUSec=5s UserStopDelayUSec=0 HandlePowerKey=poweroff HandleSuspendKey=suspend HandleHibernateKey=hibernate HandleLidSwitch=suspend HandleLidSwitchDocked=ignore HoldoffTimeoutUSec=30s IdleAction=ignore IdleActionUSec=30min PreparingForShutdown=no PreparingForSleep=no Docked=yes LidClosed=no OnExternalPower=yes RemoveIPC=yes RuntimeDirectorySize=1678897152 InhibitorsMax=8192 NCurrentInhibitors=3 SessionsMax=8192 NCurrentSessions=1
If it's just the stuff from the shared dbus-daemon changes toggling this to yes KillUserProcesses=no should fix it
(In reply to David Edmundson from comment #5) > If it's just the stuff from the shared dbus-daemon changes > > toggling this to yes > > KillUserProcesses=no > > should fix it And where should I make that change (average user here with modest knowledge)? loginctl only shows info but doesnt allow to edit it, right? Also, the available commands for loginctl don't sound like if any was a sort of editing tool: activate kill-session lock-session show-session unlock-session attach kill-user lock-sessions show-user unlock-sessions disable-linger list-seats seat-status terminate-seat user-status enable-linger list-sessions session-status terminate-session flush-devices list-users show-seat terminate-user
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
New information was added with comment 6; changing status for inspection.
Thanks Cristoph. Yes, the one who "needsinfo" is me, hehe. As soon as I can try the solution provided by D. Edmundson I'll mark this bug as resolved if said proposed solution remedies the problem. But I have no clue of where I must set "KillUserProcesses=yes" That's why I didn't anything for more than 15 days. I'll try to do some Google search by myself if I can recall it the next days.
The "KillUserProcesses=no" is from systemd, see Google's results.
*** This bug has been marked as a duplicate of bug 359651 ***
*** Bug 361471 has been marked as a duplicate of this bug. ***
*** This bug has been marked as a duplicate of bug 244250 ***