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

Package: slim; Maintainer for slim is Devuan Dev Team <devuan-dev@lists.dyne.org>; Source for slim is src:slim.

Reported by: Frank <fbug@xs4all.nl>

Date: Mon, 18 Jan 2021 20:33:01 UTC

Severity: normal

Fixed in version 1.3.6-5.2+devuan1

Done: dak@devuan.org

Forwarded to https://github.com/elogind/elogind/issues/95

Full log

🔗 View this message in rfc822 format

X-Loop: owner@bugs.devuan.org
Subject: bug#540: elogind unmounts /run/user/$UID tmpfs filesystem after logging in again
Reply-To: Frank <fbug@xs4all.nl>, 540@bugs.devuan.org
Resent-From: Frank <fbug@xs4all.nl>
Resent-To: devuan-bugs@lists.dyne.org
Resent-CC: Devuan Dev Team <devuan-dev@lists.dyne.org>
X-Loop: owner@bugs.devuan.org
Resent-Date: Wed, 20 Jan 2021 13:03:01 +0000
Resent-Message-ID: <handler.540.B540.161114700429439@bugs.devuan.org>
Resent-Sender: owner@bugs.devuan.org
X-Devuan-PR-Message: followup 540
X-Devuan-PR-Package: slim
X-Devuan-PR-Keywords: 
References: <799226dc9af49ffdf449c54e013032e1@xs4all.nl> <YAbC59HtYZjxzfBo@hindley.org.uk> <799226dc9af49ffdf449c54e013032e1@xs4all.nl> <0d28c7c8b0ca461ef8376eee0c5ec18e@xs4all.nl> <YAcjg31ZR9ilODdY@hindley.org.uk> <799226dc9af49ffdf449c54e013032e1@xs4all.nl>
Received: via spool by 540-submit@bugs.devuan.org id=B540.161114700429439
          (code B ref 540); Wed, 20 Jan 2021 13:03:01 +0000
Received: (at 540) by bugs.devuan.org; 20 Jan 2021 12:50:04 +0000
Delivered-To: devuanbugs@dyne.org
Received: from tupac3.dyne.org [195.169.149.119]
	by doc.devuan.org with IMAP (fetchmail-6.4.0.beta4)
	for <debbugs@localhost> (single-drop); Wed, 20 Jan 2021 12:50:04 +0000 (UTC)
Received: from lb1-smtp-cloud7.xs4all.net (lb1-smtp-cloud7.xs4all.net [194.109.24.24])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by vm6.ganeti.dyne.org (Postfix) with ESMTPS id 79425F60404
	for <540@bugs.devuan.org>; Wed, 20 Jan 2021 13:41:50 +0100 (CET)
Authentication-Results: vm6.ganeti.dyne.org;
	dkim=pass (2048-bit key; secure) header.d=xs4all.nl header.i=@xs4all.nl header.b="cxbHXAJ5";
	dkim-atps=neutral
Received: from webmail.xs4all.nl ([IPv6:2001:888:0:22:194:109:20:216])
	by smtp-cloud7.xs4all.net with ESMTPA
	id 2Co1lV8H8yutM2Co1leMJf; Wed, 20 Jan 2021 13:41:50 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=xs4all.nl; s=s2;
	t=1611146510; bh=0Y9GFQsHj10DLe9L6896i11916p0NqvZeFz7mfUeL2c=;
	h=MIME-Version:Date:From:To:Subject:Message-ID:Content-Type:From:
	 Subject;
	b=cxbHXAJ5Ved0NJVqUkCzS6MrKrXURsvqlOnfkWJSMFA+lkE3KD5oq8HsNRRFJhiWW
	 rtOczIO3dhresxhWCX8gbFkSYeppBzCfCeIeEwQo1wI7y2CRGf5/yEvvFS7gcRa+Dh
	 uvibuzGneEm1sx4mhwPBSWKc2pTrJD87+1MUA2V/axhagYk2cvhb4UC96EETBwJXvm
	 lk0BhvsWIjg0ovrZ5x34C8INRkZ1FAdmdlE+QWp/Th9OhK3PxGDT6TZ9YwnwPtbKsz
	 l/bAsXgbqQ+xeTY+WwN4shV1zDHkR8uPnZwifhwoddDji//nQtGVeqvqS+Vgf2kJrQ
	 GvYJ/pSrmWfZA==
Received: from roothub.nl ([83.68.19.244])
 by webmail.xs4all.nl
 with HTTP (HTTP/1.1 POST); Wed, 20 Jan 2021 13:41:49 +0100
MIME-Version: 1.0
Date: Wed, 20 Jan 2021 13:41:49 +0100
From: Frank <fbug@xs4all.nl>
To: Mark Hindley <mark@hindley.org.uk>, 540@bugs.devuan.org
In-Reply-To: <YAcjg31ZR9ilODdY@hindley.org.uk>
Message-ID: <7b2bac156d658c49f638856d445a3b3b@xs4all.nl>
X-Sender: fbug@xs4all.nl
User-Agent: XS4ALL Webmail
Content-Type: text/plain; charset=US-ASCII;
 format=flowed
Content-Transfer-Encoding: 7bit
X-CMAE-Envelope: MS4xfDQwR1+5QTjLqFBDQLx4Hyl9wEoyXOrRCzhxEUEJW/POkIeGmblBfcooIJscTV48yzfGCzWeUlSFLZliArGEJm8jVFn1QpGHnqkzRVRyNJ68A+svt35o
 wTMVHvYGMqn/JCxK8Oa8///WOmjr+TV/UqFnz6yBisIp7/N6KiOzM5uJIFiwZ4md/cvHhIWUeAa1Aswb85EVwg8NvhK77NJS5Fpz7zRozUu8Yu5Z76dI0Unk
 QhDHgYMS81NObxpdONiGmQ==
X-Spam-Status: No, score=-0.9 required=5.0 tests=DKIMWL_WL_MED,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_LOW,
	RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_PASS autolearn=disabled
	version=3.4.2
X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on tupac3.dyne.org

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/

Send a report that this bug log contains spam.

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

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