Devuan bug report logs - #540
slim fails to get logind session if logout/login cycle is rapid

Reply or subscribe to this bug.

Toggle useless messages

---

Message #5 received at submit@bugs.devuan.org (full text, mbox, reply):

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.

---

Message #8 received at 540@bugs.devuan.org (full text, mbox, reply):

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.
> 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).

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

---

Message #15 received at 540@bugs.devuan.org (full text, mbox, reply):

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:
> 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.
>> 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).
> 
> 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

---

Message #18 received at 540@bugs.devuan.org (full text, mbox, reply):

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:
> 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.

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/

---

Message #33 received at 540@bugs.devuan.org (full text, mbox, reply):

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/

---

Message #38 received at 540@bugs.devuan.org (full text, mbox, reply):

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

---

Message #43 received at 540@bugs.devuan.org (full text, mbox, reply):

On Wed, Jan 20, 2021 at 04:31:25PM +0100, Frank wrote:
> 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?

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

---

Message #48 received at 540@bugs.devuan.org (full text, mbox, reply):

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:
> On Wed, Jan 20, 2021 at 04:31:25PM +0100, Frank wrote:
>> 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?
> 
> 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

---

Message #53 received at 540@bugs.devuan.org (full text, mbox, reply):

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/

---

Message #58 received at 540@bugs.devuan.org (full text, mbox, reply):

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.
> That might be better than adding "export XDG_SESSION_CLASS=greeter" to
> "/etc/init.d/slim".

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?

> Writing Display Managers (HOWTO):
> 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

---

Message #63 received at 540@bugs.devuan.org (full text, mbox, reply):

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

Mark Hindley schreef op 2021-01-21 11:00:
> 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?
> 
>> Writing Display Managers (HOWTO):
>> 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

---

Message #68 received at 540-done@bugs.devuan.org (full text, mbox, reply):

Version: 1.3.6-5.2+devuan1

Source package slim (1.3.6-5.2+devuan1) added to Devuan suite unstable.

This closes bug report 540.

Thanks

DAK managing the Devuan archive

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Format: 1.8
Date: Thu, 21 Jan 2021 15:45:24 +0000
Source: slim
Architecture: source
Version: 1.3.6-5.2+devuan1
Distribution: unstable
Urgency: medium
Maintainer: Devuan Dev Team <devuan-dev@lists.dyne.org>
Changed-By: Mark Hindley <mark@hindley.org.uk>
Closes: 540
Changes:
 slim (1.3.6-5.2+devuan1) unstable; urgency=medium
 .
   * Set slim PAM session as class greeter. This ensures sessions
     are closed promptly on logout and we always get a session on
     a rapid logout/login cycle (Closes: #540).
   * Merge changes from debian 1.3.6-5.2 NMU.
   * d/control: add Origin: Devuan
   * d/control: update Vcs-* following Gitea migration.
Checksums-Sha1:
 27cfbd8b51acec941688a682088571d13d3fded5 1820 slim_1.3.6-5.2+devuan1.dsc
 1ac15bb91d18a6411e6561b5c1bd27268e1a1b55 34920 slim_1.3.6-5.2+devuan1.debian.tar.xz
 871d2441196a63c99c3c8005e9df9f05168c8d8e 5140 slim_1.3.6-5.2+devuan1_source.buildinfo
Checksums-Sha256:
 61219a1f733a8e8a2f68eda91018ecf8d5157b297de611c71b1b18d7054fe87e 1820 slim_1.3.6-5.2+devuan1.dsc
 40bb4c9e245f8ed4d74812d8ea40dc13f909d97b0676d8723ac93a12e65d1ae4 34920 slim_1.3.6-5.2+devuan1.debian.tar.xz
 0aebdf10f207f95702fb5837fa12749021b2316a4bfc6d70e3df1f4e69de0592 5140 slim_1.3.6-5.2+devuan1_source.buildinfo
Files:
 0303aae3315c0bacfbb9acce3e161014 1820 x11 optional slim_1.3.6-5.2+devuan1.dsc
 5882ad896f73c8e4563aeef8f78edba4 34920 x11 optional slim_1.3.6-5.2+devuan1.debian.tar.xz
 424f2ff1f49888df6e323c141d18aa2f 5140 x11 optional slim_1.3.6-5.2+devuan1_source.buildinfo

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCgAdFiEEcuPLdzMV36LkZHQ9lFMhJFQZIvsFAmAJsF4ACgkQlFMhJFQZ
Ivt15AgAjbP9z+Jzh7NCsd9sK5bxnSvinjw60Fwu4zuLI6kUAxSf9lu227kVv5+O
NKtctWFWIqxRivQbEm3fCrOg8jOIDeyC9hKyTuq5udvtfbZ85fV8iFcgvV9dXK//
DDTN9ihQM/D8iZ3GX0fCCRYlSAEHFVOiv5e9mO6v42GNwGllf9nGA8VfW7vudf0R
QSR0UyjvJ8KW6UyXzthYGmLFSuV8+9CCBh97ulIIKM/i4d0VybSwPXzX046aGeuK
/cWweBh1U16vm37Pfe94Z4q+U9bSvMVTUReAfYSqkzgny8zSt9cHtoXpVtaEN4Gs
OMtd6exc6bompQrnMdhuNyj5LDut+Q==
=b6Iq
-----END PGP SIGNATURE-----

---

Message #71 received at 540@bugs.devuan.org (full text, mbox, reply):

Здравствуйте, anal_sex_fist
 olr.page.link/kGV5#
Amets!

Информация о регистрации на сайте: http://deluxe-style.ru
Логин: 540@bugs.devuan.org
Пароль: Тот, который вы указали при регистрации.

Для подтверждения регистрации перейдите по ссылке:
http://deluxe-style.ru/users/?accept=089EF2A8-EDE3-20AE-A870-F4C303B8032A

Для отмены регистрации перейдите по ссылке:
http://deluxe-style.ru/users/?cancel=089EF2A8-EDE3-20AE-A870-F4C303B8032A

С уважением, администрация сайта.

---

Message #76 received at 540@bugs.devuan.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

 <https://www.hootholidays.com.au/>           amy_fisher_sex
ijq.page.link/oXrE# zinge amy_fisher_sex ijq.page.link/oXrE# zinge,

 Welcome to Main Website Store.

  To sign in to our site, use these credentials during checkout or on the
My Account <https://www.hootholidays.com.au/customer/account/> page: 

   -  *Email:* 540@bugs.devuan.org
  -  *Password:* *Password you set when creating account* 
 
  Forgot your account password? Click here
<https://www.hootholidays.com.au/customer/account/createPassword/?id=951&amp;token=1a6768e47645f258510ece11a3ec47f2>
to reset it. 

 When you sign in to your account, you will be able to:

   - Proceed through checkout faster
  - Check the status of orders
  - View past orders
  - Store alternative addresses (for shipping to multiple family members
and friends)
 
            1300 654 732 <tel:1300%20654%20732>   Your next holiday is only
a call away! <https://www.facebook.com/hootholidays/>
<https://www.instagram.com/hootholidays/>
<https://twitter.com/HootHolidays>
<http://www.pinterest.com.au/hootholidays/>
<https://www.youtube.com/channel/UCGcRQpAqUXqUxW6meC7F50A?view_as=subscriber>

[Message part 2 (text/html, inline)]

---

Message #81 received at 540@bugs.devuan.org (full text, mbox, reply):

Hi amy_fisher_sex

Thanks for subscribing to the Hoot Holidays email list. To complete your subscription, you need to confirm you got this email. To do so, please click the link below:

------------------------------

http://hootholidays.cmail20.com/t/j-c-dijhtyljhl

------------------------------


If you subscribed in error or no longer want to hear from us, click the link below and you will be instantly removed from our list:

http://hootholidays.cmail20.com/t/j-u-l_jlyuxk-dijhtyljhl/

---

Message #86 received at 540@bugs.devuan.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

The best value holiday delas straight to your inbox!

No images?  Click here https://hootholidays.cmail20.com/t/j-e-wnch-dijhtyljhl-ti/

Thank you for signing up to Hoot Holidays.

Expect great holiday deals straight to your inbox.

We love great holiday deals, but we also know that not everyone wants the same holiday. To help us send you the best value holiday deals that are most relevant to you, please click the button below and update your preferences. Let us know which destinations you would like to hear about and how you travel.

UPDATE YOUR PREFERENCES HERE https://hootholidays.updatemyprofile.com/j-wnch-1AFFEAC7-dijhtyljhl-td                                               Australia [https://www.hootholidays.com.au/destinations/australia] |   [https://www.hootholidays.com.au/destinations/fiji] Fiji [https://www.hootholidays.com.au/destinations/fiji] |  Vanuatu [https://www.hootholidays.com.au/destinations/vanuatu] | Cook Islands |  Norfolk Island [https://www.hootholidays.com.au/destinations/other/norfolk-island]  Samoa [https://www.hootholidays.com.au/destinations/samoa]   [https://www.hootholidays.com.au/destinations/samoa]|  Thailand [https://www.hootholidays.com.au/destinations/thailand] |  Vietnam [https://www.hootholidays.com.au/destinations/vietnam] |  Bali [https://www.hootholidays.com.au/destinations/bali] |  Hawaii [https://www.hootholidays.com.au/destinations/hawaii] |  Other destinations [https://www.hootholidays.com.au/destinations/other]

Our mission is happier holidays for everyone

– over 300,000 so far!

40 years' experience working with top airlines, resorts and operators means we negotiate the best deals to create tailor-made, value-packed packages. And if it’s not any of these deals you’re after, ask us about our other exclusive deals.

Preferences https://hootholidays.updatemyprofile.com/j-wnch-1AFFEAC7-dijhtyljhl-th  |   Unsubscribe https://hootholidays.cmail20.com/t/j-u-wnch-dijhtyljhl-tk/

[Message part 2 (text/html, inline)]

---

Send a report that this bug log contains spam.

---