:: [devuan-dev] bug#540: elogind unmou…
Pàgina inicial
Delete this message
Reply to this message
Autor: Frank
Data:  
A: Mark Hindley, 540
Assumpte: [devuan-dev] bug#540: elogind unmounts /run/user/$UID tmpfs filesystem after logging in again
I agree with you that the issue it not easy to fix. I ran into it when I
was configuring my .xsessionrc and could not figure out what I did wrong
in order to break the runtime directory. I usually just login once a day
at most, so I won't run into the issue very often.

At least the workaround - add "UserStopDelaySec=infinity" to section
[Login] in config file /etc/elogind/logind.conf - works, but isn't great
either. Perhaps it would be best to deprecate Slim and switch the
default DM to either LightDM or SDDM?

Anyway, I'll play around with the Slim config and PAM config some more
(until I get bored). If I find a solution (against all odds) I'll let
you know.

> I believe the issue is with the way slim opens and closes the logind
> session. It
> takes time to close the session when you logout. If you logout and then
> back in
> quickly (which you indicated was a requirement to trigger the bug), the
> previous
> slim session is still closing and, hence /run/user/$UID gets unmounted
> for the
> second login. The umount is actually a symptom of the fact that the
> second login
> has no logind session at all. You should be able to verify that with
> the
> loginctl command.
>
> If you have a short (about 15s IIRC) wait before logging back in, the
> first
> session has closed properly and everything should work normally.
>
> Having said that I think I have seen this before and know what is going
> on, as
> Sven pointed out in the upstream bug, we could not find a solution
> within
> slim. slim upstream is dormant and has not been updated 2014[1].
>
> Other than documenting not to log out and back in very quickly, I am
> unsure what
> else we can do. Do you think that would be enough?
>
> [1] https://sourceforge.net/projects/slim.berlios/