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.