SUMMARY Session logout does not terminate running processes / mounted filesystems and they delay further operations. STEPS TO REPRODUCE 1. login with any user 2. start Firefox or Thunderbird 3. logout OBSERVED RESULT The following processes are typically left behind: > pgrep -au <user> /usr/lib/systemd/systemd --user (sd-pam) /usr/lib/gvfs/gvfsd-fuse /run/user/1000/gvfs -f -o big_writes Login back with the same user causes issues with Dbus and if a shutdown was requested, the system waits 2 minutes for them to terminate before proceeding. EXPECTED RESULT All user-related processes that got started during the session should be terminated during logout. SOFTWARE/OS VERSIONS Linux: OpenSUSE 15.1 KDE Plasma Version: 5.12.8 KDE Frameworks Version: 5.55.0 Qt Version: 5.9.7 ADDITIONAL INFORMATION The workaround I put in place was to execute fusermount -u as part of the logout process. See: https://unix.stackexchange.com/questions/590095/shutdown-is-slow-always-waiting-2-minutes-for-gvfsd-fuse-to-terminate
I'm seeing this problem. A number of processes - including kwin_x11 - are hanging about after logout. I've also noticed that scripts in ~/.config/plasma-workspace/shutdown appear not to be run, as the processes they should kill are also still there after logout. Plasma 5.19.1, openSUSE 15.1 precompiled binaries. Seen on two separate machines.
(In reply to S. Bryant from comment #1) > I'm seeing this problem. A number of processes - including kwin_x11 - are > hanging about after logout. > > I've also noticed that scripts in ~/.config/plasma-workspace/shutdown appear > not to be run, as the processes they should kill are also still there after > logout. > > Plasma 5.19.1, openSUSE 15.1 precompiled binaries. Seen on two separate > machines. I use a script to enable hdmi full range after login and logout also fails on my system. Probably a regression, see bug 421676.
To test if it's related to another task does qdbus org.kde.Shutdown /Shutdown org.kde.Shutdown.logoutAndShutdown shutdown the computer for you or logout?
(In reply to David Edmundson from comment #3) > To test if it's related to another task does > > qdbus org.kde.Shutdown /Shutdown org.kde.Shutdown.logoutAndShutdown > > shutdown the computer for you or logout? shutdown. SOFTWARE/OS VERSIONS Operating System: Arch Linux KDE Plasma Version: 5.19.1 KDE Frameworks Version: 5.71.0 Qt Version: 5.15
(In reply to David Edmundson from comment #3) > To test if it's related to another task does > > qdbus org.kde.Shutdown /Shutdown org.kde.Shutdown.logoutAndShutdown > > shutdown the computer for you or logout? I tested on two machines. One shut down, the other only logged out. Both are 5.19.1.
(In reply to David Edmundson from comment #3) > qdbus org.kde.Shutdown /Shutdown org.kde.Shutdown.logoutAndShutdown With openSuse 15.1 I get: Service 'org.kde.Shutdown' does not exist. giving the command with the current user or root.
New information was added with recent comments; changing status for inspection.
This report has become a mix of too many conflicting things. If gvfs lingers, that lies with gvfs. If logout scripts are broken make a new report.
> This report has become a mix of too many conflicting things. I must disagree. Given that a number of programs that used to terminate no longer do so, it seems reasonable to assume there is a common problem. That problem may be outside of ksmserver, however. It would be nice to narrow things down. Can you (David) confirm that no processes linger on your system? Here's a list of lingering programs after logout on this system (now with Plasma 5.19.2): /usr/lib/systemd/systemd --user (sd-pam) /usr/bin/dbus-daemon --session --address=systemd: --nofork --nopidfile --systemd-activation --syslog-only /usr/lib/gvfs/gvfsd /usr/lib/gvfs/gvfsd-fuse /run/user/1026/gvfs -f -o big_writes /usr/lib/at-spi2/at-spi-bus-launcher /usr/bin/dbus-daemon --config-file=/usr/share/defaults/at-spi2/accessibility.conf --nofork --print-address 3 /usr/bin/kwin_x11 /usr/lib/dconf-service /usr/bin/baloo_file /usr/lib/bluetooth/obexd /usr/bin/ksystemstats /usr/bin/ksysguardd /usr/lib/GConf/2/gconfd-2 /usr/lib64/libexec/kf5/kio_http_cache_cleaner > If gvfs lingers, that lies with gvfs. Is that true for the others too? > If logout scripts are broken make a new report. Fair enough, let's ignore those in this bug report. Given that it's not possible to log in after logging out (unless the processes are manually killed), the "not a bug" status is incorrect. BTW: the original report mentioned shutdown waits for 2 minutes. This is after the display manager has exited - it's one of the system scripts waiting for user processes to terminate so partitions can be unmounted. It's not Plasma waiting for 2 minutes.
*** This bug has been marked as a duplicate of bug 359651 ***
*** This bug has been marked as a duplicate of bug 244250 ***
Most of these come down to dbus activation A change a few years ago means dbus daemon persists across multiple graphical sessions, our activated stuff has no way to know this, so anything without an X connection just persists. A hacky workaround (that gnome also do) is to restart dbus-daemon on logout. try putting: systemctl --user restart dbus.service in an executable shell script in .config/plasma-workspace/shutdown and report back The correct fix is the new systemd boot, there we can explicitly scope dbus-activated things to the graphical session rather than having dbus-daemon handle the lifespan
possibly bug 421676 is a duplicate.
*** Bug 421676 has been marked as a duplicate of this bug. ***
*** Bug 385829 has been marked as a duplicate of this bug. ***
(In reply to David Edmundson from comment #12) > try putting: systemctl --user restart dbus.service > in an executable shell script in > > .config/plasma-workspace/shutdown > > and report back OK.. tried that. Unfortunately it stopped the logout procedure, and left X sort of hanging. The mouse moved, but there was nothing clickable, and no response to keyboard shortcuts (eg: Alt-F2 etc). I had to Ctrl-Alt-Bksp the X-Server, after which I noticed a number of programs were still hanging about (more than previously). I tried adding 'sleep 2' to the script before the restart command, but it made no difference.
*** Bug 407305 has been marked as a duplicate of this bug. ***
*** This bug has been marked as a duplicate of bug 424408 ***