Subject: elogind unmounts /run/user/$UID tmpfs filesystem after logging in again

From: Frank <[email-masked]>
Date: Mon, 18 Jan 2021 21:12:24 +0100

Package: elogind
Version: 241.4-2

elogind unmounts /run/user/$UID tmpfs filesystem after logging in again. 
It should not do that.

Devuan was installed using the Refracta installer that is available on 
the iso-file devuan_beowulf_3.0.0_amd64_desktop-live.iso.
Unable to reproduce the issue in a VM booted of iso-file 
devuan_beowulf_3.0.0_i386_desktop-live.iso / 
devuan_beowulf_3.0.0_amd64_desktop-live.iso.

Steps to reproduce (new install, new user, default settings):
1) login to the XFCE desktop environment.
2) in a terminal window, exec df. This shows, amongst others, a tmpfs 
filesystem mounted at /run/user/$UID.
3) log out and log back in (rapidly).
4) in a terminal window, exec watch df. This shows, amongst others, the 
same tmpfs filesystem mounted at /run/user/$UID.
5) wait and watch closely.
6) df no longer shows the tmpfs filesystem mounted at /run/user/$UID, it 
was unmounted by elogind even though the user is still logged in.

Workaround: at "UserStopDelaySec=infinity" to section [Login] in config 
file /etc/elogind/logind.conf. The tmpfs mounted at /run/user/$UID will 
remain available until system reboot.
Workaround: after logout, wait for the tmpfs mounted at /run/user/$UID 
to be unmounted.

---

From: Mark Hindley <[email-masked]>
Date: Tue, 19 Jan 2021 11:30:47 +0000

Control: tags -1 moreinfo

Frank,

Thanks for this.

On Mon, Jan 18, 2021 at 09:12:24PM +0100, Frank wrote:
> Package: elogind
> Version: 241.4-2
> 
> elogind unmounts /run/user/$UID tmpfs filesystem after logging in again. It
> should not do that.
> 
> Devuan was installed using the Refracta installer that is available on the
> iso-file devuan_beowulf_3.0.0_amd64_desktop-live.iso.

Your comment about 'rapidly' reminds me of an issue I have seen before[1]. It is
only apparent using slim as DM and is really a bug in slim. Can you confirm if
that is what you have been using?

Thanks

Mark

[1]  https://github.com/elogind/elogind/issues/95

---

From: Frank <[email-masked]>
Date: Tue, 19 Jan 2021 14:51:03 +0100

Hi Mark,

I am using slim, this is the default DM in Beowulf.
Not sure if the issue is related to the bug you are referring to.

I also tested with a bare minimum xsession with xterm; the issue remains 
the same.
So I would say, the issue is either with slim or elogind, or the 
combination of the two.

Regards,
Frank

Mark Hindley schreef op 2021-01-19 12:30:
>> the

---

From: Mark Hindley <[email-masked]>
Date: Tue, 19 Jan 2021 18:22:59 +0000

Control: reassign -1 slim
Control: retitle slim fails to get logind session if logout/login cycle is rapid
Control: tags -1 -moreinfo
Control: forwarded -1 https://github.com/elogind/elogind/issues/95

Frank,

On Tue, Jan 19, 2021 at 02:51:03PM +0100, Frank wrote:
> I also tested with a bare minimum xsession with xterm; the issue remains the
> same.
> So I would say, the issue is either with slim or elogind, or the combination
> of the two.

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/

---

From: Mark Hindley <[email-masked]>
Date: Tue, 19 Jan 2021 18:34:49 +0000

retitle 540 slim fails to get logind session if logout/login cycle is rapid

---

From: Frank <[email-masked]>
Date: Wed, 20 Jan 2021 13:41:49 +0100

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.

---

From: Frank <[email-masked]>
Date: Wed, 20 Jan 2021 16:31:25 +0100

Hi Mark,

I played around with the slim PAM configuration and found a possible 
solution: change the elogind class from "user" to "greeter". Slim does 
not fork a helper process so changing it makes sense to me. When a new 
session is created, previous sessions close in the background, even if 
the logout/login cycle is rapid. Looks promising?

This is what I changed (needs polishing, obviously):

--- common-session	2020-05-30 17:32:28.000000000 +0200
+++ common-session-slim	2021-01-20 16:01:33.521567369 +0100
@@ -22,5 +22,5 @@
  session	required			pam_permit.so
  # and here are more per-package modules (the "Additional" block)
  session	required	pam_unix.so
-session	optional			pam_elogind.so
+session	optional	pam_elogind.so class=greeter
  # end of pam-auth-update config

--- slim.orig	2020-01-07 12:09:49.000000000 +0100
+++ slim	2021-01-20 15:55:39.223866000 +0100
@@ -14,7 +14,7 @@
  session [success=ok ignore=ignore module_unknown=ignore default=bad]    
pam_selinux.so close
  session required        pam_limits.so
  session required        pam_loginuid.so
-@include common-session
+@include common-session-slim
  # SELinux needs to intervene at login time to ensure that the process
  # starts in the proper default security context. Only sessions which 
are
  # intended to run in the user's context should be run after this.

The result:
---------------------------- snip -------------------------------
devuan@devuan:~$ loginctl list-sessions; loginctl session-status
SESSION  UID USER   SEAT  TTY
       1 1000 devuan seat0
      c3 1000 devuan seat0

2 sessions listed.
c3 - devuan (1000)
            Since: Wed 2021-01-20 16:04:01 CET; 2s ago
           Leader: 4556 (slim)
             Seat: seat0; vc7
          Display: :0.0
           Remote: user root
          Service: slim; type x11; class greeter
            State: active
---------------------------- snip -------------------------------

Regards,
Frank

> 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.
> 
> [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?
>

---

From: Mark Hindley <[email-masked]>
Date: Wed, 20 Jan 2021 17:11:30 +0000

On Wed, Jan 20, 2021 at 04:31:25PM +0100, Frank wrote:
> solution: change the elogind class from "user" to "greeter". Slim does not
> fork a helper process so changing it makes sense to me. When a new session
> is created, previous sessions close in the background, even if the
> logout/login cycle is rapid. Looks promising?

Interesting. I am wondering (from a very quick read of the docs) if we can
achieve the same by setting XDG_SESSION_CLASS within slim.

Thanks.

Mark

---

From: Frank <[email-masked]>
Date: Wed, 20 Jan 2021 19:07:17 +0100

Adding "pam.setenv("XDG_SESSION_CLASS", "greeter");" to app.cpp (line 
560) did not work for me, the environment variable is set, but the class 
(according to cmd "loginctl session-status") is still "user". But, 
adding "export XDG_SESSION_CLASS=greeter" to "/etc/init.d/slim" DID 
work, class became "greeter". Even better. Nice and clean.

Mark Hindley schreef op 2021-01-20 18:11:
>> not

---

From: Frank <[email-masked]>
Date: Wed, 20 Jan 2021 20:15:25 +0100

Adding "pam.setenv("XDG_SESSION_CLASS", "greeter");" to app.cpp, line 
228, also works.
That might be better than adding "export XDG_SESSION_CLASS=greeter" to 
"/etc/init.d/slim".

The decision is yours.

More info:
[gdm] pam: set XDG_SESSION_CLASS variable to "greeter" when setting up 
greeter PAM session: 
https://mail.gnome.org/archives/commits-list/2012-March/msg08054.html
Writing Display Managers (HOWTO): 
https://www.freedesktop.org/wiki/Software/systemd/writing-display-managers/

---

From: Mark Hindley <[email-masked]>
Date: Thu, 21 Jan 2021 10:00:10 +0000

Frank,

Thanks. Very helpful.

On Wed, Jan 20, 2021 at 08:15:25PM +0100, Frank wrote:
> Adding "pam.setenv("XDG_SESSION_CLASS", "greeter");" to app.cpp, line 228,
> also works.

I am still trying to fully understand the implications of this.

It certainly makes sense for the slim login screen to be greeter class. But,
semantically, I would also expect the subsequent user login to be class user. I
don't yet know what other effects (if any) having the user login as class
greeter has.

Maybe we unset XDG_SESSION_CLASS again before pam.open_session? But maybe that
would no longer fix the issue you came across?

> https://www.freedesktop.org/wiki/Software/systemd/writing-display-managers/

This seems to confirm that the user login itself should not be class greeter.

Mark

---

From: Frank <[email-masked]>
Date: Thu, 21 Jan 2021 15:19:55 +0100

Hi Mark,

Cmd "loginctl session-status" shows that class "greeter" is a property 
of service "slim". It looks fine to me since slim does not fork a helper 
process like, for example, lightdm does.

XDG_SESSION_CLASS is set by PAM module pam_elogind.so. Unsetting 
XDG_SESSION_CLASS / changing it to "user" again before pam.open_session 
breaks the fix. Overriding the environment variable by adding 
"pam.setenv("XDG_SESSION_CLASS", "greeter");" to app.cpp (line 560) 
won't change the class, just the variable (see below).

----------------- snip ---------------
devuan@devuan:~$ loginctl session-status | grep Service; set | grep 
XDG_SESSION
	 Service: slim; type x11; class greeter
XDG_SESSION_CLASS=user
XDG_SESSION_ID=1
XDG_SESSION_TYPE=x11
----------------- snip ---------------

I did a quick check in the logind source code and as far as I can see a 
greeter session does not have any additional privileges compared to a 
user session. There is only have_multiple_sessions() in logind-dbus.c 
that checks if there are multiple sessions; greeter sessions are not 
counted.

Slim is a single process (class "greeter") without a helper (class 
"user"). Changing the class to greeter is the best you can do.

Regards,
Frank