Your message dated Mon, 31 Aug 2026 17:43:19 +0200 with message-id <[email protected]> and subject line Re: Bug#1146329: light-locker screen lock becomes permanently unresponsive (black screen) after failed SwitchToGreeter on seat with CanMultiSession=no has caused the Debian Bug report #1146329, regarding light-locker screen lock becomes permanently unresponsive (black screen) after failed SwitchToGreeter on seat with CanMultiSession=no to be marked as done.
This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact [email protected] immediately.) -- 1146329: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1146329 Debian Bug Tracking System Contact [email protected] with problems
--- Begin Message ---Package: lightdm Version: 1.33.0-1 Severity: important Tags: upstream d-i X-Debbugs-Cc: Subject: light-locker screen lock becomes permanently unresponsive (black screen) after failed SwitchToGreeter on seat with CanMultiSession=no Since upgrading lightdm from 1.32.0-7+b1 to 1.33.0-1 (2026-08-17, the first new upstream release after ~4 years), locking the screen via light-locker reliably (every time, both on manual lock and on idle-triggered lock via xfce4-power-manager) results in a permanently black, unresponsive screen: no keyboard or mouse input (including the laptop's internal keyboard) is accepted. The X session itself is NOT frozen or crashed - only recoverable by switching to another VT and manually killing/relaunching light-locker. System: Kali GNU/Linux Rolling 2026.3 (Debian-based), kernel 6.16.8+kali-amd64, Intel TigerLake-LP Iris Xe Graphics (i915), XFCE desktop. Relevant package versions: lightdm 1.33.0-1 (was 1.32.0-7+b1 for >3 months before, no issue) light-locker 1.8.0-3+b1 (unchanged for >1 year) xfce4-power-manager 4.20.1-1 (was 4.20.0-1 for >1 year, bumped same day as lightdm; considered as secondary/ aggravating factor, not primary trigger, since 4.20.0 ran symptom-free for months) systemd 261.2-1 / libpam-systemd 261.2-1 Steps to reproduce (100% reproducible, confirmed on demand, not just on idle-triggered locks): 1. Log into an XFCE session on seat0 (single local seat, no multi-seat). 2. Lock the screen - either manually (Super+L / Ctrl+Alt+L, both bound to xflock4), via xfce4-power-manager's blank-on-idle (here set to 3 minutes), or simply by running `xflock4` directly. 3. The screen goes black and stays black; no input (keyboard/mouse, including the laptop's own internal keyboard) is accepted. The screen never returns to the unlock prompt. Diagnosis performed so far: - No kernel/DRM/i915 errors in `journalctl -k` around the incident. - Xorg itself never crashes; the X server stays alive and responsive to other clients throughout the freeze (confirmed via `xset q` succeeding from another session with DISPLAY=:0 while the screen was black: "DPMS is Enabled" / "Monitor is On" - i.e. this is NOT a real DPMS blank, the monitor is on, it's light-locker's own black window/grab that is stuck). - /proc/<light-locker pid>/stack while frozen shows a perfectly healthy idle wait, not a crash or deadlock: poll_schedule_timeout.constprop.0 do_sys_poll __x64_sys_ppoll do_syscall_64 entry_SYSCALL_64_after_hwframe i.e. light-locker is just blocked in ppoll() waiting for an event that never arrives. - DEFINITIVE CONFIRMATION: while the screen was black, I injected a synthetic key event from another session via `DISPLAY=:0 XAUTHORITY=... xdotool key shift`, then immediately re-read light-locker's kernel stack. It was byte-for-byte IDENTICAL before and after the injection (same ppoll() frame, State: S). The process never wakes up in response to the injected input at all. This rules out a bug in light-locker's own event-handling code (it never even receives the event to mishandle) and confirms the input grab is lost/never (re)acquired at the X server level after the failed SwitchToGreeter negotiation with lightdm. - Killing light-locker (`pkill light-locker`, no -HUP needed since it has no SIGHUP handler and terminates on receipt) immediately restores full desktop access with ZERO loss of the running X session/applications - proving Xorg/xfwm4 were healthy the whole time and the problem is strictly confined to light-locker's lock-window/grab. - light-locker's own binary strings show it implements a "switch to greeter" locking strategy against lightdm before falling back to a plain X grab: Send switch greeter / Refusing to switch to greeter / SwitchToGreeter Switch to greeter timeout / Start switch to greeter timer - /var/log/lightdm/lightdm.log for every single lock event (four separate occurrences captured across two different days, including one triggered on demand for testing) shows lightdm explicitly refusing the switch, always with the same message: DEBUG: Seat seat0 has property CanMultiSession=no ... DEBUG: Seat seat0: Unable to switch to greeter because the seat already has a session and does not support session switching This CanMultiSession=no property appears to be inherent to a plain local single seat (not something we changed/introduced with this upgrade) - so it seems light-locker's "switch to greeter" attempt was always going to be refused on this kind of seat, but the resulting fallback-to-grab path apparently no longer completes correctly since the 1.33.0 upgrade (light-locker just sits in ppoll() forever instead of grabbing input itself). - lightdm.conf was checked against the new 1.33.0 packaged default (/etc/lightdm/lightdm.conf.dpkg-dist was left behind by the upgrade): the only differences are cosmetic (comment formatting, an unrelated commented-out VNC depth default) - no behavioural config change. This looks like a regression in how light-locker's fallback-to-grab logic interacts with lightdm's (possibly changed) D-Bus response/timing around a refused SwitchToGreeter request, specifically on seats without multi-session support (i.e. the overwhelmingly common single-seat laptop case). A closely related failure mode (switch-to-greeter timer starts, callback never fires, screen stays black, only fixable by killing light-locker) was previously reported upstream against light-locker after a systemd version bump: https://github.com/the-cavalry/light-locker/issues/146 (closed without a fix). That report explicitly said CanMultiSession was not involved in their case, so this may be a second, distinct trigger for the same underlying fragile fallback path in light-locker, newly exposed by lightdm 1.33.0. I have also filed a corresponding report upstream against light-locker: https://github.com/the-cavalry/light-locker/issues/<fill in after posting> Workaround currently in use (no data loss, but has to be repeated every single lock/unlock cycle): 1. From a different VT (as root): pkill light-locker 2. From a terminal *inside* the running desktop session (not via sudo/su from another tty - see below): light-locker & Note: relaunching light-locker via `sudo -u <user> ... light-locker &` from another tty/session fails immediately with: ERROR: session_id is not set, is /proc mounted with hidepid>0? This is because light-locker determines its session via sd_pid_get_session() based on process cgroup membership, not environment variables - a process started from a different logind session's cgroup (e.g. via su/sudo from a rescue tty) can never satisfy this check, regardless of DISPLAY/XAUTHORITY/ DBUS_SESSION_BUS_ADDRESS/XDG_SESSION_ID being set correctly. It must be launched as a native child of the actual graphical session. I'm happy to provide the full lightdm.log / light-locker stack dumps from further occurrences if useful - this is 100% reproducible on this machine, on demand, every single lock. -- System Information: Debian Release: n/a (Kali GNU/Linux Rolling 2026.3) APT prefers kali-rolling Architecture: amd64 Kernel: Linux 6.16.8+kali-amd64 (SMP w/ CPUs; PREEMPT_DYNAMIC) -- *Luca Petrocchi* [email protected]
--- End Message ---
--- Begin Message ---Version: 1.33.1-1 On Mon, Aug 31, 2026 at 02:09:44PM +0200, Luca Petrocchi wrote: > Package: lightdm > Version: 1.33.0-1 > Severity: important > Tags: upstream d-i > X-Debbugs-Cc: > > Subject: light-locker screen lock becomes permanently unresponsive (black > screen) after failed SwitchToGreeter on seat with CanMultiSession=no Hi, Apart from things mentioned by Yves-Alexis, this should have been fixed in Debian with lightdm 1.33.1-1, already in Debian sid. Please see #1143981 [lightdm: Session unlock broken with light-locker] #1144037 [Does not switch users after upgrading to lightdm 1.33.0-1] for more details. I am thus closing this bug report. Please contact Kali about this change reaching Kali. Regards, -- Agustin
--- End Message ---
