Bug#1018102: idle detection failure
On 2022-09-14 21:41:52, Antoine Beaupré wrote: > That seems to say that this command is supposed to trigger a lock: > > loginctl lock-session > > and it does *not* work here. Does it work for you? So, interestingly, this issue has mostly gone away from my workstations now, after a general cleanup of old packages. In particular, the above command *does* work now, which makes me believe that this is a systemd/logind issue, where some service (which?! who knows!) might be inhibiting lock. How to tell *what* that is is beyond me right now, but it's a heck of a tell, i think... -- Quis custodiet ipsos custodes? Who watches the watchmen? Qui police la police? Tu. You. Toi.
Bug#1018102: idle detection failure
Oh and I found more information about this in the arch wiki:
https://wiki.archlinux.org/title/Session_lock#xss-lock
That seems to say that this command is supposed to trigger a lock:
loginctl lock-session
and it does *not* work here. Does it work for you?
It seems the `xset s` mechanism i am using is the "DPMS" hook. They do
have a note there:
> Note: When using xss-lock with DPMS, you will have to blank the screen
> yourself. It will not be triggered when looking at videos.
It is not exactly to me what that means ("blank the screen
yourself"??). But it does hint that something else (a video player i
guess?) will prevent screen locking, which begs the question of what
qualifies as a video player. Maybe if i have a video player playing
somewhere that I didn't know about? I did have a tab opened on some
youtube thing earlier, but i tried closing that tab (and indeed, all of
firefox in fact) and that didn't do it.
It would sure be nice if one could tell wth is preventing this thing
from sending locking signals. :)
I also found out on that wiki that you can use systemd to send those
signals:
https://wiki.archlinux.org/title/Session_lock#Inactivity
... but considering that loginctl lock-session doesn't work in the first
place, i wonder how this could work at all anyways... maybe worth a try?
--
Freedom is being able to make decisions that affect mainly you. Power
is being able to make decisions that affect others more than you. If
we confuse power with freedom, we will fail to uphold real freedom.
- Richard Stallman
Bug#1018102: idle detection failure
On 2022-09-04 07:57:11, Ian Campbell wrote: > On Thu, 2022-08-25 at 13:27 -0400, Antoine Beaupre wrote: >> I have xss-lock setup to start xsecurelock automatically after the >> delay prescribed by my `xset` configuration. > > FWIW I've never seen it used with xsecurelock (I use i3lock) but I do > `xset b off` in my session (but not the `s 60 3` thing you do) and > autolocking does work for me as expected -- although in practice mostly > lock via a key binding as I walk away, but if I forget it does lock > itself. Hmm... `xset b off` just turns off the bell, it doesn't touch the screen saver at all.. how does that relate? >> I wonder if I'm missing a key service in my session, or how to debug >> the screensaver in Xorg > > I'm afraid I don't know about any of this sort stuff, I just package > the tool as a user. Gotcha. :) > As you say `xset s activate` works I'm inclined to suggest the issue is > elsewhere in the stack. But here are some random thoughts nonetheless: > > You pass --verbose but I assume the journald output for xss- > lock.service has nothing of use? So interestingly, today, I reproduced this on another workstation which I didn't expect would have this problem. Here's the journal of that service since last boot: sep 14 08:42:59 emma systemd[2011]: Started xss-lock - use external locker as X screen saver. sep 14 08:56:51 emma xss-lock[2115]: notifier exited abnormally: Le processus fils a été tué par le signal 15 sep 14 13:24:54 emma xss-lock[2115]: notifier exited abnormally: Le processus fils a été tué par le signal 15 sep 14 13:32:21 emma xss-lock[2115]: notifier exited abnormally: Le processus fils a été tué par le signal 15 I'm not sure what those errors are about, but when I returned to the computer just now, the screen was unlocked. > You could switch xsecurelock out for a wrapper which logs and then > forwards to the real thing, at least then you would know if it was > being called at all. I am pretty confident xsecurelock is not being called at all. > Have you compared the process lists on the working and non-working > systems, that might give a hint about a missing process/service in your > session. I have not, since now the working machine is actually broken so it's hard for me to access that information (i'd need to restore from backups)... > Perhaps also look for anything which is inhibiting screenlock, e.g. a > "Presentation Mode" setting? I think this is logind related > functionality so perhaps there is a way to query the underlying setting > via that? In the past I've seen these options having different setting > for mains power vs battery, which could explain a laptop vs desktop > difference. Yeah, so that's definitely an interesting avenue. I looked at loginctl and it says my session is "active": anarcat@emma:~$ loginctl session-status | grep State State: active anarcat@emma:~$ loginctl user-status | grep State State: active I am not sure if that's what we're looking for. I have tried xprintidle: https://github.com/g0hl1n/xprintidle So I did this: xset s 5 3 watch xprintidle I can see the idle counter incrementing past 5 seconds, and the screen doesn't lock. I have also tried to replace xsecurelock with this wrapper, and can confirm it never gets called (the echo doesn't show up and the stamp file is not created): #!/bin/sh echo "callling xsecurelock" touch $XDG_RUNTIME_DIR/xsecurelock.stamp exec xsecurelock So there is one of two things happening: 1. xprintidle believes Xorg is idle while it is really not 2. xorg is not telling xss-lock about idleness for some reason I am not sure I believe 1. And I don't know how to debug 2. Happy to test more ideas. :) -- Be who you are and say what you feel Because those who mind don't matter And those who matter don't mind. - Dr. Seuss
Bug#1018102: idle detection failure
On Thu, 2022-08-25 at 13:27 -0400, Antoine Beaupre wrote: > I have xss-lock setup to start xsecurelock automatically after the > delay prescribed by my `xset` configuration. FWIW I've never seen it used with xsecurelock (I use i3lock) but I do `xset b off` in my session (but not the `s 60 3` thing you do) and autolocking does work for me as expected -- although in practice mostly lock via a key binding as I walk away, but if I forget it does lock itself. > I wonder if I'm missing a key service in my session, or how to debug > the screensaver in Xorg I'm afraid I don't know about any of this sort stuff, I just package the tool as a user. As you say `xset s activate` works I'm inclined to suggest the issue is elsewhere in the stack. But here are some random thoughts nonetheless: You pass --verbose but I assume the journald output for xss- lock.service has nothing of use? You could switch xsecurelock out for a wrapper which logs and then forwards to the real thing, at least then you would know if it was being called at all. Have you compared the process lists on the working and non-working systems, that might give a hint about a missing process/service in your session. Perhaps also look for anything which is inhibiting screenlock, e.g. a "Presentation Mode" setting? I think this is logind related functionality so perhaps there is a way to query the underlying setting via that? In the past I've seen these options having different setting for mains power vs battery, which could explain a laptop vs desktop difference. Ian.
Bug#1018102: idle detection failure
Package: xss-lock
Version: 0.3.0-10+b1
Severity: important
I have xss-lock setup to start xsecurelock automatically after the
delay prescribed by my `xset` configuration.
Basically, I have this in my .config/systemd/user/xset.service:
[Unit]
Description=Miscellaneous settings for X11
PartOf=graphical-session.target
[Service]
# `b off` disables the audible bell
# http://netbuz.org/blog/2011/11/x-bells-and-urgency-hints/
# `s IDLE BLANK` is the screensaver setup
# start after 1 minute idle, then lock in 3 seconds
# the blank timeout corresponds to the dimmer delay
# (XSECURELOCK_BLANK_TIMEOUT) in ~/.xsecurelock.env
ExecStart=/usr/bin/xset b off s 60 3
Type=oneshot
RemainAfterExit=false
[Install]
WantedBy=graphical-session.target
... and this in my .config/systemd/user/xss-lock.service:
[Unit]
Description=xss-lock - use external locker as X screen saver
Documentation=man:xss-lock(1)
PartOf=graphical-session.target
Wants=xset.service
After=xset.service
[Service]
Type=simple
EnvironmentFile=/home/anarcat/.xsecurelock.env
ExecStart=/usr/bin/xss-lock --verbose --transfer-sleep-lock
--session=${XDG_SESSION_ID} --notifier /usr/libexec/xsecurelock/dimmer --
xsecurelock
[Install]
WantedBy=graphical-session.target
In general, this works: on my laptop, right now, the screen correctly
locked after 60 seconds. But on my desktop, right now, the screen does
*not* lock after 60 seconds.
Calling `xset s activate` *does* lock the screen though, so xss-lock
is correctly behaving on that part. I have tried lowering the delay as
well (`xset s 3 3`, wait 3 seconds), no effect: it's as if my session
is not seen as idle by Xorg.
I suspect this is hard to reproduce: I seem to recall this workstation
correctly locking itself, but I'm not sure.
I wonder if I'm missing a key service in my session, or how to debug
the screensaver in Xorg (or if I should just switch to wayland already
anyways... ;)
Thanks for any help you can give me!
-- System Information:
Debian Release: 11.4
APT prefers stable-security
APT policy: (500, 'stable-security'), (500, 'stable-debug'), (500, 'stable'),
(1, 'unstable'), (1, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.10.0-16-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_FIRMWARE_WORKAROUND,
TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages xss-lock depends on:
ii libc62.31-13+deb11u3
ii libglib2.0-0 2.66.8-1
ii libxcb-screensaver0 1.14-3
ii libxcb-util1 0.4.0-1+b1
ii libxcb1 1.14-3
xss-lock recommends no packages.
xss-lock suggests no packages.
-- debconf-show failed
