light-locker hangs on "This session is locked"

Norkos · 2019-09-11 08:06:13

Hi,

I using LightDM (light-locker) and Gnome.

Problem:

After locking the screen (super+l) the gui freezes on the "This session is locked" screen

Screenshot: https://imgur.com/R78OU59

After reboot the first lock/unlock works, the second ends in the freeze.

Workarround:

On freeze:

* switching to TTY (ctrl+alt+F2),
* logging in
* call "loginctl unlock-sessions"
* switch back (ctrl+alt+F7)

To avoid the freeze:

Dont lock with "ctrl+l" or GUI, use this instead:

dm-tool lock

Since When

09./10. Sep 2019 - after updating Systemd & Kernel.
LightDM got no update.

Logs

Update-Log: https://filebin.net/nqig9p2yuz89ginv/up … t=g6rw7dsv
Journal-Log: https://filebin.net/nqig9p2yuz89ginv/jo … t=wr4onc4z

Additional Infos

[09:54:35 ~]$ light-locker --debug
[gs_debug_init] gs-debug.c:106 (10:52:19):	 Debugging enabled
[main] light-locker.c:142 (10:52:19):	 initializing light-locker 1.8.0
[main] light-locker.c:164 (10:52:19):	 Platform:
gtk:        3
systemd:    yes
ConsoleKit: no
UPower:     no
[main] light-locker.c:196 (10:52:19):	 Features:
lock-after-screensaver: yes
late-locking:           yes
lock-on-suspend:        yes
lock-on-lid:            no
settings backend:       GSETTINGS
[main] light-locker.c:198 (10:52:19):	 lock after screensaver 0
[main] light-locker.c:199 (10:52:19):	 late locking 0
[main] light-locker.c:200 (10:52:19):	 lock on suspend 0
[main] light-locker.c:201 (10:52:19):	 lock on lid 0
[main] light-locker.c:202 (10:52:19):	 idle hint 0
[init_session_id] gs-listener-dbus.c:2193 (10:52:19):	 Got session-id: /org/freedesktop/login1/session/_32
[init_session_id] gs-listener-dbus.c:2198 (10:52:19):	 Got sd-session-id: 2
[init_seat_path] gs-listener-dbus.c:2279 (10:52:19):	 Got seat: /org/freedesktop/DisplayManager/Seat0

** (light-locker:8950): WARNING **: 10:52:19.740: screensaver already running in this session

Last edited by Norkos (2019-09-11 10:15:42)

QuickS1lver · 2019-09-11 09:01:27

So I had been having this issue, too. After the latest updates, light-locker flat-out stopped redirecting to the greeter after running the lock command.

Your "additional info" is actually unrelated, it's just light-locker saying that you're already running an instance of it (ie. the one started when you first logged in). Try killing that process

$ killall light-locker

and then run your command again.

I actually went down a similar debug process as what you seem to, and found that when I restarted light-locker as above, it functioned fine again.

Last edited by QuickS1lver (2019-09-11 09:01:45)

kyrisu · 2019-09-11 09:30:57

I'm also experiencing this issue for the last few days (lightdm worked flawlesly before).

I log in by opening another console (CTRL+ALT+F2) and unlocking the session from there:

loginctl list-sessions
loginctl unlock-session X

Where X is the number of the session from the first command.

Norkos · 2019-09-11 09:40:25

Thanks for your reply.

After killing the light-locker the process became a zombie:

$ ps -e --forest
#...
   5045 ?        00:00:00 lightdm
   5050 tty7     00:00:02  \_ Xorg
   5163 ?        00:00:00  \_ lightdm
   5172 ?        00:00:00  |   \_ gnome-session-b
   5177 ?        00:00:00  |       \_ light-locker <defunct>
   5206 ?        00:00:05  |       \_ gnome-shell
   5223 ?        00:00:00  |       |   \_ ibus-daemon
#...

running

$ light-locker --debug

gives me the same output as in the start post.

Restarting lightdm...

$ sudo systemctl restart lightdm.service

...kind of works, but on the next lock I got the same behavior (and of course, the gnome-session is gone).
Also this behavior can be repeatedly reproduced : reboot -> lock -> unlock -> lock => error

QuickS1lver · 2019-09-11 10:00:10

I guess because it is started by XDG Autostart when your session is started. I'm running i3wm, so the startup is just a line in my i3 config.

One option to get the debug output then could be to change the command exec in

/etc/xdg/autostart/light-locker.desktop

to include the --debug switch and pipe the output to somewhere you can find it, or otherwise disable the autostart and then try running the command manually as before.

Last edited by QuickS1lver (2019-09-11 10:03:39)

Norkos · 2019-09-11 10:13:44

I changed the "/etc/xdg/autostart/light-locker.desktop" to:

Exec=light-locker --debug > /tmp/light-locker-debug

But the log did not appear.

---

Also I found another workaround:

$ dm-tool lock

locks the screen as expected.

Could it be that the problem the communication between gnome and light-locker is?

QuickS1lver · 2019-09-11 12:00:54

Looks like I spoke too soon, I'm getting the same issue as you. It locks properly the first time but not any of the following times.
On the plus side, I have got debug logs:

$ light-locker --debug

Initial run:
https://hastebin.com/efodiwuced.sql

First lock:
https://hastebin.com/efukaherun.cpp

Second lock:
https://hastebin.com/axiyezemet.cpp

There are some differences between the two, but I can't pretend to know what's going on with it. On the plus side, since I'm not using Gnome, it rules out it being an issue with that.

Norkos · 2019-09-11 12:57:33

QuickS1lver wrote:

On the plus side, since I'm not using Gnome, it rules out it being an issue with that.

So maybe it's an Systemd problem?

I still don't know what the call-pipeline looks like. Maybe so:

GUI (User) -> Gnome -> Systemd (loginctl)? -> light-locker

While "dm-tool" calls directly light-locker (or ligthdm).
I tested the different ways:

# Gnome -> Error
$ dbus-send --type=method_call --dest=org.gnome.ScreenSaver /org/gnome/ScreenSaver org.gnome.ScreenSaver.Lock

# Systemd -> Error
$ loginctl lock-session

# lightdm -> OK
$ dm-tool lock

In the meanwhile I just override my lock-hotkeys (super+l) with the command "dm-tool lock".

Last edited by Norkos (2019-09-11 13:02:43)

Norkos · 2019-09-11 13:39:56

QuickS1lver wrote:

There are some differences between the two, but I can't pretend to know what's going on with it.

I've done a quick diff and there are almost the same besides on the second log some lightdm releated outputs are missing:

[gs_manager_timed_switch] gs-manager.c:445 (12:43:17):	 Start switch to greeter timer
...
[gs_listener_send_lock_session] gs-listener-dbus.c:180 (12:43:18):	 Send lock session
...
[gs_manager_stop_switch] gs-manager.c:456 (12:43:20):	 Stop switch to greeter timer
[listener_dbus_handle_system_message] gs-listener-dbus.c:1343 (12:43:20):	 obj_path=/org/freedesktop/login1/session/_32 interface=org.freedesktop.login1.Session method=Lock destination=(null)

So to be more specific: Its seems to be a problem with the lock not the unlock.
I assume that light-locker can't switch to the lock (maybe the call is wrong or it never happens).

Btw.: I did the dbus method call from above and got the same issue (freezed lock screen)

Norkos · 2019-09-11 15:37:02

I took a look on the code of lightdm, dm-tool and light-locker.
And found partiality an answer of my question "how the call-pipe looks like": There are several D-Bus interfaces.

The dm-tool calls the Lock method on org.freedesktop.DisplayManager.Seat on which lightdm directly listens. This call is working as expected.

Light-locker itself listen and calls several D-Bus interfaces: https://github.com/the-cavalry/light-lo … c/gs-bus.h
So the missing log message "Start switch to greeter timer" should be triggered by a dbus-call.

In systemd I found the org.freedesktop.login1.Session.Lock call: https://github.com/systemd/systemd/blob … ion-dbus.c
There was a bug in the last release about sessions-switching, it should be fixed, but maybe this bug is related.

I will stop for now and will say: In doubt, systemd is debt

PixelatedPizza · 2019-09-11 21:04:21

On Xfce4 calling "xflock4" in order to lock the screen via a keyboard shortcut will cause the issue to appear.

I went and changed the shortcut to "dm-tool lock" just like Norkos and it seems to fix it.

toz · 2019-09-11 22:49:09

PixelatedPizza wrote:

On Xfce4 calling "xflock4" in order to lock the screen via a keyboard shortcut will cause the issue to appear.
I went and changed the shortcut to "dm-tool lock" just like Norkos and it seems to fix it.

See: https://wiki.archlinux.org/index.php/Xf … the_screen. You can specify "dm-tool lock" as the custom command for xflock4 to process via an xfconf setting.

zesaver · 2019-09-16 10:47:23

The same issue on i3dm + lightlocker. Changing keybinding to "dm-tool lock" seems to do the trick.

jones · 2019-09-19 19:18:37

I experienced the problem as well, it went away with specifying "dm-tool lock" as the command for the keyboard shortcut and in /usr/bin/xflock4. However the problem persists if the screen gets locked due to inactivity.

guraltsev · 2019-09-22 14:57:48

I am also affected by this issue, exactly as described. The problem persists when the screen gets locked out on idle time-out. Is there a bug report that has been filed?

nimrod_mack · 2019-09-24 16:37:39

Ahh I'm so glad I'm not the only one with that problem. For me, the quick fix for the past couple of weeks was downgrading systemd, systemd-libs and systemd-sysvcompat to the latest 242 release. But I'm glad to know the dm-tool quickfix also works.

I couldn't find any relevant bug reports for systemd, light-locker or lightdm... the bug has so far occured to me in any systemd-243 version tested (243.0 and 243-51) and I guess it's an upstream bug. But I have no idea of the inner workings of those mechanisms...

citrus · 2019-09-29 10:00:31

Experiencing the same bug. Any news on the cause?

citrus · 2019-09-29 10:08:24

Did some basic research, found the following bug reports related to this:

- https://bugs.debian.org/cgi-bin/bugrepo … bug=929834
- https://github.com/the-cavalry/light-locker/issues/146
- https://github.com/the-cavalry/light-locker/issues/126

All of these are fresh (just several days old at the time of posting this).

After some more reading, it seems like the cause of the problem is systemd commit "3b92c08"
See: https://github.com/systemd/systemd/comm … d03d10cfb5

There are some indications that reverting to a revision before this effectively mitigates the bug.

jones · 2019-10-04 15:48:42

So, the issue now turned into something new, but I am posting this as it might still be based on the same underlying problem (perhaps, not sure!).

Even if I activate the screenlock via dm-tool lock, I now cannot get back in. The situation is as follows:

I activated the screenlock is activated and the screen is black.
After I enter my password, the screen turns back on.
It goes into Arch/my DE, i. e. I see the normal XFCE environment with whatever window is activated.
After a split second, it logs out again and I see the login window.
I can enter my password again, however the same spiel from the 2 points above happens.

Basically I have to use another TTY to unlock my session on TTY7.

kocsv · 2019-10-22 05:17:33

Haven't tested, yet (@work) but there seems to be some activity:
https://github.com/systemd/systemd/pull/13811

Edit: After the second standby it froze again

Last edited by kocsv (2019-10-22 15:35:46)

atmarx · 2019-10-24 00:49:07

Good eye. Hopefully just a few more days.

I saw systemd in the pacman list yesterday and got excited... but that patch still hasn't gone out the door yet. It would be nice not to have to switch to another tty and unlock the session manually anymore.

balzak · 2019-11-06 21:43:22

Can anyone confirm if this was fixed by 243.78-2?

rgarcia · 2019-11-06 22:56:21

balzak wrote:

Can anyone confirm if this was fixed by 243.78-2?

No, it doesn't fix it. 243.78-2 doesn't seem to include the fix though.

loqs · 2019-11-07 00:06:43

You try building systemd locally with the commits from https://github.com/systemd/systemd/pull/13811

diff --git a/trunk/PKGBUILD b/trunk/PKGBUILD
index 9648a3e..120d4a0 100644
--- a/trunk/PKGBUILD
+++ b/trunk/PKGBUILD
@@ -64,6 +64,9 @@ sha512sums=('SKIP'
 _backports=(
   # Revert "sysusers: properly mark generated accounts as locked" 
   '12c829376a95ee0a734b8dbd347042062516f0a9'
+  '4b9e5848e31cb2efb606a5292a2d2abb6ba35040'
+  '8cc64c2a3640121745fdfaccc6eae896ac25a911'
+  '8163b9f90079af298031dcbffee057fc344470a3'
 )
 
 _reverts=(

The pull request included four commits but I dropped the mailmap: add entry to fix authorship of commit as not relevant
Edit:
https://bbs.archlinux.org/viewtopic.php … 3#p1872413 contains step by step instructions to build the package locally.

Last edited by loqs (2019-11-08 23:12:17)

rgarcia · 2019-11-08 23:47:21

@loqs - Thanks, can confirm that the issue is gone after applying the patch.

Arch Linux

#1 2019-09-11 08:06:13