On Sun, Jan 08, 2017 at 09:32:25PM +0100, Martin Pitt wrote: > Julian Andres Klode [2017-01-08 19:13 +0100]: > > (1) Seems you install to lib/systemd/system - but the service would have to > > be > > in lib/systemd/user to work (it's a user service) > > That makes little sense IMHO -- the systemd user instance needs to be able to > see ~/.config/systemd/user/ at startup, and on logout all user processes > including systemd need to stop before you will be able to unmount the > unencrypted $HOME --
Not really. Otherwise it would not work that way. There's only a problem if some files are open, which apparently the systemd --user instance does not have. Since we do not have any user service, and all other user sessions are gone by the time systemd user session shuts down, it sort of works. Even if there are other user services running, those are AFAICT shutdown in shutdown.target. This service in contrast has After=shutdown.target and is pulled in via exit.target. It's a workaround, it works on my PC and my parent's one since 2 years, but I can't say I'm running extreme systemd user sessions. > so the mount/unmount needs to be done by a PAM module > (pam_ecryptfs). This works just fine in Ubuntu at least (I've used ecryptfs on > my $HOME for many years). Really? That said, Ubuntu switched with 15.04, and I reported the bug in 14. But then László can reproduce it now it seems, so I don't think that's really fixed anywhere. Then it's really a question of why this happens in Debian (and others[1][2]) and not in Ubuntu. Or debugging the pam module. Either way, I'd really like to see this fixed. [1] Fedora: https://bugzilla.redhat.com/show_bug.cgi?id=1175675 [2] OpenSUSE/Mageia: https://bugs.freedesktop.org/show_bug.cgi?id=72759 -- Debian Developer - deb.li/jak | jak-linux.org - free software dev | Ubuntu Core Developer | When replying, only quote what is necessary, and write each reply directly below the part(s) it pertains to ('inline'). Thank you.
