Summary: | Systemd user manager interferes with ecryptfs - private directory not being unmounted | ||
---|---|---|---|
Product: | systemd | Reporter: | Neil Rickert <rickert> |
Component: | general | Assignee: | systemd-bugs |
Status: | RESOLVED NOTOURBUG | QA Contact: | systemd-bugs |
Severity: | normal | ||
Priority: | high | CC: | bruce, dziltener, matthias_dienstbier, ronan, tez |
Version: | unspecified | ||
Hardware: | x86-64 (AMD64) | ||
OS: | Linux (All) | ||
Whiteboard: | |||
i915 platform: | i915 features: |
Description
Neil Rickert
2013-12-16 15:32:14 UTC
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.