-
Notifications
You must be signed in to change notification settings - Fork 37
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Can't log to another user after logout #187
Comments
Thank you for the report. This seems like a new problem, I appreciate all the investigative work. I am guessing somehow the work we are doing on |
I am met with the same issue (currently testing with sway, but it happens with other sessions too). When trying to start sway for the 2nd time I get:
This issue can only be solved by restarting lemurs. My assumption is lemurs is either blocking the logind access for sway or is otherwise making it impossible for sway to check the user's active session. |
Looking deeper into this I think I found the culprit:
When looking at the user's status it becomes clear that lemurs lowered itself into the session scope, but never exited (the below omits non-useful data) and is the only process keeping that seat alive:
|
Looking at the above, my assumption would be, that lemurs needs to exit at that point in time to free the seat, or lower a process into that seat (for handling) which may exit. When choosing the first route I guess lemurs.service would have to be able to automatically restart. As is, lemurs blocks a login after an initial login and logout, because the lemurs presented to the user at that point runs in the scope of the session that the previous user exited. |
@dvzrv when |
Lol just hit this problem this morning...so happy to help fix :) |
Wellp, in my case I actually just figured it out. My binary for hyprland was Hyprland with a capital H so lemurs was trying (because I configured it to) to use the |
@dvzrv I can confirm the same behavior. Lemurs is sitting on the scope being closed.
To be honest, the only thing I can tell Lemurs does at this point is write to the logs. So I think it should actually just exit? I don't know why it needs to exist after you log in. Apparently it does lower the execution to the user scope: https://github.com/coastalwhite/lemurs/blob/main/src/post_login/mod.rs#L72-L97 I'm not great with this stuff, but it does look like there's some spawning issues.
So 702 is in the old session, whereas 706 is a child in the new session. I performed I think this happens because we spawn a child process (script) and that may not be receiving the SIGTERM. https://github.com/coastalwhite/lemurs/blob/main/src/post_login/wait_with_log.rs#L88-L92 At this point I'm stumped. Also note: I'm using wayland. |
OK, new hunch. Looking through my logs I noticed the following log:
which comes from https://github.com/coastalwhite/lemurs/blob/main/src/auth/utmpx.rs#L94 this is called in the main method https://github.com/coastalwhite/lemurs/blob/main/src/main.rs#L352
Actually it does: Lines 11 to 12 in 1d4be7d
Or that the UI thread keeps looping after a successful login 🤔 https://github.com/coastalwhite/lemurs/blob/main/src/ui/mod.rs#L463 Adding a break there really mucks things up. |
Was playing around with
Seems like it just sits on this futex until I send it a sigterm. |
I’ve also hit this and found a workaround. I’ve just provided init scripts for non-systemd init systems like OpenRC, sysvinit and s6 with #217 and am using a slightly improved OpenRC script based on the one in the Gentoo user repository. The OpenRC script automatically restarts lemurs after kills. I have noticed that quite a few processes remain after closing my sway session, so I figured, that I need to kill those sticky processes. Otherwise I would duplicate them on relogin. With that setup I use the following to stop my Sway session.
Apparently it is also required to change the vt for lemurs to be able to restart. Probably the tty can’t be taken over by openvt otherwise. With this setup I can reliably relogin after logout. Maybe this helps someone. In my experience other display managers usually restart on logout. Maybe lemurs should do something similar. I somehow doubt, that the session otherwise can be closed properly. |
@coastalwhite did you have opportunity to look into this issue? |
I also cannot log back in as the same user |
Hi, thanks for this project !
I just did a fresh installation of Arch with XFCE. I need to have two different users, let's say
alice
andbob
.So I followed the instructions, and after booting my computer, Lemurs works perfectly fine and I can easily log into any user. Once I have logged out, I get back to Lemurs as expected. If I try to log to the same user, it will work fine once again. However, if I try to log to the other user, I get to a screen with nothing but this :
Which translates to :
I can't find my mouse, and the keyboard becomes unresponsive on this tty.
Here's what I have in my
journalctl -xeu lemurs
:The errors about
pam_loginuid
happen when I log in for the first time, where it seemingly work without problems.I tried to disable lemurs, and to switch between users without any display manager, on the same tty, by launching XFCE just with the
startxfce4
script. It works without issues.Here is the
/var/log/lemurs.log
I obtain when I first succesfully log asalice
, logout, and then fail to log asbob
:lemurs.client.log
andlemurs.xorg.log
are empty.Something strange that I noticed is that when I boot my computer, successfully log in a
alice
for example, then logout to go back to lemurs, if I go to another tty and typeloginctl
, this is what I get:Where we can see that the session which is supposed to be closed, is stuck in the
closing
state...I don't know what to do, I'm not even sure where the problem comes from. Was a multi-users setup tested on lemurs ?
Thanks.
The text was updated successfully, but these errors were encountered: