Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
Only get session on alternate login #95
I am still debugging my build of v239-stable that we are testing to upload to Debian.
At the moment I see 3 unexpected and maybe related issues:
[ 68.563706] elogind-daemon: New seat seat0.
I suspect the last is a symptom of the first.
I am using -Dcgroup-controller=elogind. Built on debian sid but with polkit-1 115 from debian experimental.
Have I made a mistake with the build?
They should unless a session can be re-used. This is how it looks on my system, after I had some fun logging in/out on TTY2-TTY4:
XDG_SESSION_ID is set by pam_elogin.so. I haven't tried out slim, but with SDDM it is always set unless I 'su' to root.
I am currently installing slim, maybe I can find something out ...
Maybe that has something to do with a mistake I made when writing the patch for polkit-1.115 to support elogind. Please check whether the patch from here is applied:
But I think it is alright, or no sessions would be created at all...
HA! I just logged into OpenBox using SLiM, and XDG_SESSION_ID is not set, and loginctl returns an empty list. (if I log into Plasma, XDG_SESSION_ID is always set.)
The logs show this:
(The first line is from logging out of Plasma.)
For SDDM the logs show:
When I go comparing to what happens when I use SDDM versus SLiM, a line containing
But I have to dig deeper...
On Mon, Nov 12, 2018 at 05:37:58PM +0000, Sven Eden wrote: When I go comparing to what happens when I use SDDM versus SLiM, a line containing kernel: elogind-daemon: Removed session <id> is missing for the latter. So it looks like the logging off isn't reported to elogind. But I have to dig deeper...
I am glad you found something -- I have been banging my head against this for days thinking I am missing something! Thanks. Mark
I think this is an upstream bug of either SLiM or PAM.
But when things end, SLiM only calls pam.close_session();. Does this only close its own session? Is the closing of the user session first required here?
This is how login-logout-login look with SDDM starting OpenBox:
And this is how it looks for SLiM, also using OpenBox:
Can you see how it takes 20 seconds (timeout, maybe?) until the closing of the session in SLiM reaches elogind, but is instant with SDDM?
What puzzles me is that the log messages come from pam_unix. So why does it take 20 seconds to close the session with elogind via SLiM, but is instant with SDDM?
The SLiM pam config in /etc/pam.d/slim is quite rudimentary. It delegates everything to system-local-login, which delegates everything to system-login, which includes system-auth, which eventually calls pam_elogind for session inclusion.
The SDDM pam config in /etc/pam.d/sddm-greeter is more thorough, but behind the scene it does basically the same.
I have found out something else. If I wait for the 20 seconds before logging back into OpenBox with SLiM, everything works as expected, but I get the same session ID:
This is odd, but understandable if we look into the session status as reported by loginctl:
As you can see, slim is still there and listed as both "Leader" and "Service", with root being listed as Remote participant.
With SDDM it looks like this in a running session:
Here sddm is the session leader, but sddm-helper has already closed its session. SLiM has not done something like that, as it does not spawn a helper. At least as far as I could see.
When I log out of OpenBox after using SLiM and check the session-status on a TTY within this 20 seconds delay, I get this:
The session is closing. And the session leader, slim, isn't there any more. SLiM restarts and gets a new PID (or at least re-forks) when you log out of anything.
These exact 20 seconds puzzle me. I will check session handling and finalizing in elogind tonight. Maybe it is something we can fix within elogind. Maybe the session closing in SLiM only needs to be re-organized a bit. WE'll see.
On Tue, Nov 13, 2018 at 12:41:31AM -0800, Sven Eden wrote: These exact 20 seconds puzzle me. I will check session handling and finalizing in elogind tonight. Maybe it is something we can fix within elogind. Maybe the session closing in SLiM only needs to be re-organized a bit. WE'll see.
Thanks, that fits with most of what I saw. I have changed to lightdm which seems to operate similarly to sddm. The other part of this that is still incomplete is polkit integration. We are trying to use elogind in a Debian sid install which also has libsystemd0 (but no other systemd components). In this setup, polkit fails to map pids to sessions, normally replying with "no session for PID" type errors. This is with polkit from experimental (version 0.115) compiled by Debian against libsystemd0. I have done my own compilation of polkit 0.115 against libelogind0 (with your extra patch for configure.ac from issue #54 to correctly build the right backend). This which works as expected, but I am wondering if we can avoid this and get elogind to work with polkit compiled against libsystemd0? Thanks for your help. Our first packaging of elogind has gone into the Debian incomming queue this afternoon :) Mark
No, you can't.
HA! Maybe I have a solution.
Take a look at this:
The delay was added to speed up re-logins, as the users service manager (private systemd instance) would not be restarted so often thanks to this enhancement.
I am currently testing a possible fix. :-)
Nope, not there, yet.
The delay has dropped from 20 to 11 seconds. This is caused by the user simply not logging out directly. Something is holding that back.
When PAM calls elogind to release the session, it is not stopped, but a 20 seconds timer is started. Once that is over, the session is torn down. This is done like this since 2014, to ensure, that a user is logged out properly. And it does, as the 20 second limit isn't even reached.
I have made elogind to ignore sessions that are already closing, or scheduled for closing. But then SLiM itself is occupying the old session, so we still won't get a new one.
So what I will try next, is to look again into the SLiM sources to find out how much work would be involved to teach it to start its own session. This way the restarted slim process (or re-forked) won't occupy the closing session of the user.
On Tue, Nov 13, 2018 at 08:25:54AM -0800, Sven Eden wrote: This which works as expected, but I am wondering if we can avoid this and get elogind to work with polkit compiled against libsystemd0? No, you can't. systemd stores session information differently than elogind does, with user unitsand scopes. elogind can not support either and uses internal hash containers. So when polkit asks libsystemd for a session id to a pid, it will search for a session-.scope and find nothing. Please see here: https://github.com/elogind/elogind/blob/d4a3f29/src/basic/cgroup-util.c #L1713 That's the function that gets called to do the task eventually.
Thanks, that is helpful. I hadn't managed to spot that distinction. Mark
@markhindley : I think we are hitting a dead end here.
If I am not much mistaken, SLiM has to be tought to fork a helper process that drops its privileges to a distinct SLiM user, so it can have its own session being created. Then, when the user logs in, that helper simply quits, releasing its session.
That the current SLiM version is from 2013-10-02, and hasn't seen any activity since then, doesn't help either.
Unless someone forks it and takes care of it, I do not see much hope. We could patch it (to death), but maybe it would be better to warn users, that they should not do fast re-logins if they use elogind.
systemd spawns a service manager per user, I guess that works around the problem. But I haven't done any research in that direction.
Absolutely! That timeout is surely useful for systemd, but for elogind it doesn't do anything else than lagging the user logout.
Before pushing that change and closing this issue, I want to test a theory of mine tonight. Currently, at least as far as I remember, there is no check whether the session leader PID (in this case from the SLiM process that just went away) really belongs to a living process.
added a commit
Nov 15, 2018
On Wed, Nov 14, 2018 at 10:10:21PM -0800, Sven Eden wrote: Unfortunately my idea was fruitless. SLiM does a single fork, keeping itself as session leader around. This can not be patched away easily, at least as far as I can see.
OK, Thanks for trying. I am just rebuilding to test with user_stop_delay removed Mark
On Thu, Nov 15, 2018 at 09:40:32AM +0000, Mark Hindley wrote: On Wed, Nov 14, 2018 at 10:10:21PM -0800, Sven Eden wrote: > Unfortunately my idea was fruitless. > > SLiM does a single fork, keeping itself as session leader around. This > can not be patched away easily, at least as far as I can see. OK, Thanks for trying. I am just rebuilding to test with user_stop_delay removed
Works well for me. I am happy for you to close this. Thanks very much. Mark