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
