Version: unspecified (using KDE 4.4.4) OS: Linux On logout, KDE leaves gam_server, akonadi_control, akonadiserver, and mysqld running (parent process is init). After enough time elapses, they shut down, so this is not a critical problem when logging out. When shutting down, however, the process are still apparently updating the akonadi data set when the parent system attempts to unmount the directory that they're running from (typically $HOME). At least when $HOME is a network mount, this seems to cause data corruption and the dreaded "akonadi crash on takeoff" problem. Reproducible: Always Steps to Reproduce: Start KDE 4.4.4, including kmail or other kontact clients of akonadi on an nfs mount. Once started, log out. Observe processes running with lsof -N Alternately: Modify /etc/init.d/nfsmount to log running NFS processes (lsof -N) Instead of logging out, use the KDE shutdown or reboot command. Observe that there were nfs processes (as listed above) at shutdown. Instead of logging out, instruct the system to shut down. Actual Results: Processes running at nfs unmount: gam_server akonadi_control akonadiserver mysqld Expected Results: Empty list: KDE should ensure that these processes actually shut down before issuing "telinit 6" I haven't found any suggestion of akonadiserver maintaining a count of mysqld clients (which would be in order if the instance was intended to be shared) nor of waiting for child to die. If I recall my Unix fundamentals correctly, waiting for a unique instance of mysqld, akonadiserver, etc. to die should be trivial.
I can actually confirm this problem! When using kerberized NFS home directories, this becomes a huge problem, as the users kerberos kredentials get deleted at logout. Thus, filesystem access is blocked to the users home for any remaining processes and the /var/log/messages gets spammed with errors due to the KDE "zombies". My list of KDE processes left running with a UID of the (logged out) user is: kdm knotify4 virtuoso-t klauncher kdesud kdeinit4 kded4 akonadi_control akonadiserver mysqld dbus-launch dbus-daemon nepomukserver It would be nice if KDE could ensure that all these processes quit after the user logs out. Or at least create an option somewhere that allows the admin to enable such a feature!
> kredentials get deleted at logout Who deletes them? Shouldn't they be only deleted, when all processes have exited?
pam_krb or pam_sssd delete Kerberos credentials (which were saved in /tmp/ at login) on logout. That's the default PAM behaviour in terms of Kerberos, as far as I know, in order to not leave credential caches lying around. If a users explicitly want to keep jobs running after PAM logout, he/she must take care of providing valid credentials to these jobs him/herself, which he can easily do running an 'kinit' or other ways. I would suggest that KDE does not leave any of the processes KDE started itself (i.e., all processes not started by the user) running in the users name. Of course, that may be difficult to figure out. At our institution we are running a bash script that kills all the above mentioned processes, if no user of the name they are running as is logged in.
I can confirm as well on Arch Linux x64. I am using an encrypted home directory which is mounted automatically using pam_mount. However, pam_mount will not unmount the user's home directory on logout as it is still in use by these processes. It does unmount correctly when logging into/out of the console.
I can confirm this bug still exists in KDE 4.9.5 on Gentoo Linux x86. Encrypted home directories will auto-unmount when logging out from a console, but not when logging out from KDE. At a minimum, gam_server is still running after logging out.
(In reply to comment #4) > I can confirm as well on Arch Linux x64. I am using an encrypted home > directory which is mounted automatically using pam_mount. However, pam_mount > will not unmount the user's home directory on logout as it is still in use > by these processes. > > It does unmount correctly when logging into/out of the console. Have the same problem with KDE 4.11.2 on Arch Linux 64bit. When I login to KDE, then the encrypted $HOME can be mounted by pam_mount. When I logout from my KDE session, then my encrypted $HOME can't be unmounted by pam_mount because there are active handles on the mountpoint: Nov 2 16:55:13 bart kdm: :0[1518]: command: '/usr/bin/umount.crypt' '/home/user' Nov 2 16:55:13 bart kdm: :0[1518]: (mount.c:68): umount messages: Nov 2 16:55:13 bart kdm: :0[1518]: (mount.c:72): NOTE: mount.crypt does not support utab (systems with no mtab or read-only mtab) yet. This means that you will temporarily need to call umount.crypt(8) rather than umount(8) to get crypto volumes unmounted. Nov 2 16:55:13 bart kdm: :0[1518]: (mount.c:72): umount: /home/user: target is busy Nov 2 16:55:13 bart kdm: :0[1518]: (mount.c:72): (In some cases useful info about processes that Nov 2 16:55:13 bart kdm: :0[1518]: (mount.c:72): use the device is found by lsof(8) or fuser(1).) Nov 2 16:55:13 bart kdm: :0[1518]: (mount.c:72): umount /home/user failed with run_sync status 2 Nov 2 16:55:17 bart kdm: :0[1518]: (mount.c:888): unmount of /dev/mapper/vg_root-lv_user failed
using KDE 4.14.13... gamin_server is still running when xorg is stopped, so NFS /home fails to unmount. Its CWD is /home/$user. This hangs the shutdown maybe forever, but if you wait long enough I think gamin_server eventually stops... but the shutdown still hangs. I tested by going to single user mode, which hung, but ctrl+c got out of it and I could see gamin_server still running for a few minutes. (and then shutdown still hung...not sure why; one lame thing in Linux is when shutdown hangs, there's no shell left running to investigate)
*** This bug has been marked as a duplicate of bug 359651 ***
*** Bug 362142 has been marked as a duplicate of this bug. ***
*** Bug 417889 has been marked as a duplicate of this bug. ***
*** Bug 361471 has been marked as a duplicate of this bug. ***
*** Bug 427111 has been marked as a duplicate of this bug. ***
*** Bug 422322 has been marked as a duplicate of this bug. ***
This bug is a myriad of multiple things to the point of being completely useless. It's not going to get anywhere. I'm going to close this, and reopen one of the more modern ones: 422322