This is observed with opensuse 13.1, using an ecryptfs private directory. On one computer, I am using an encrypted home directory with ecryptfs. On logout, the private directory remains mounted (so visible decrypted). I see this as a security concern. If I remove systemd from the pam configuration, the ecryptfs reverts to working as it should. Example: on my work computer, I use an encrypted home directory. I logout when I leave work. A remote login from home (ssh with public key authentication) shows that the encrypted home directory is still mounted. The command "ecryptfs-umount-private" tells me that the directory is mounted in another session. Repeating "ecryptfs-umount-private" does unmount it. Thereafter, ecryptfs works properly until the next boot. I tried "systemctl --user exit" in a KDE exit script. That shuts down the user manager process, but it does not fix the problem with the ecryptfs private directory remaining mounted. My best guess is that the systemd is creating an additional pam session for this user, and never exiting that session. And this throws of the session counting by the ecryptfs pam module.
systemd is not in the business of unmounting home directories.
The answer referred to the symptoms, not the bug. The bug is that systemd leaves something about the user "logged in" even after the user logs out. Thus in my system the SYMPTOM is that when I try to run reboot as user after I have logged out as root, I get an error message saying that user root is still logged in and this blocks the reboot. Another symptom is that systemd --user and (sd-pam) are left running for that logged out user even after that user (in my case aboove root) has logged out. So running in runlevel 3 on Mageia 4.1 newly updated, if I first log in as root immediately log out as root (so I get another login request on the runlevel 3 terminal) and log in as unruh ( user 500) and then try to run reboot, I get an error message from systemd saying User root is logged in on tty1 Please retry operation after closing inhibitors and logging out other users. The other users ARE logged out. As another SYMPTOM, if I log in as user, run poweroff or reboot, I get, after a number of messages, a timeout of 90 sec on User Manager failing. 90 sec completely defeats the stated purpose of systemd to speed up boots and halts.
I can't believe it. It's 2019 and this bug is still not fixed. Why exactly is RedHat still paying your salary?
> I can't believe it. It's 2019 and this bug is still not fixed. Why exactly is RedHat still paying your salary? I understand this bug report is important to you. It's not really high up on my list however, and to my knowledge my employer never supported ecryptfs, hence both to me and my employer this bug isn't of particular importance. If you require this issue to be fixed, please consider filing a support request to the distribution of your choice that supports ecryptfs, and I am sure they'll help you, and make sure the bug is fixed and the bugfix contributed upstream. Other than that, I doubt anything will change about this issue any time soon.
So, let's close this. This needs to be fixed by ecryptfs. The user@.service instance (i.e. systemd's --user instance) runs through the PAM session hooks like any other PAM session, hence if ecryptfs properly unmounts its home directory when the last PAM session of the user dies, then all should work, correctly. Note that for performance reasons the --user instance sticks around for a bit longer after the user logged out completely, but that should be OK, the PAM session exit hook is called when it exits, and that should be all that ecryptfs needs to umount things. Hence, closing.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.