i3lock option 'n' not working properly

[chorcheus]

I'm submitting a…

[x] Bug
[ ] Feature Request
[ ] Other (Please describe in detail)

Current Behavior

When running

xautolock -time 5 -locker 'lockscript.sh'

while lockscript.sh looks like:

#!/bin/bash

echo $(date) Locking the screen >> lock.log
i3lock -n
echo $(date) Unlocking the screen >> lock.log

The file lock.log looks like this:

Tue 04 Feb 2020 11:54:10 PM CET Locking the screen
Tue 04 Feb 2020 11:54:19 PM CET Unlocking the screen
Tue 04 Feb 2020 11:59:20 PM CET Locking the screen
Tue 04 Feb 2020 11:59:30 PM CET Unlocking the screen
Wed 05 Feb 2020 12:04:30 AM CET Locking the screen
Wed 05 Feb 2020 12:04:40 AM CET Unlocking the screen
Wed 05 Feb 2020 12:09:40 AM CET Locking the screen
Wed 05 Feb 2020 12:09:49 AM CET Unlocking the screen
Wed 05 Feb 2020 12:14:50 AM CET Locking the screen
Wed 05 Feb 2020 12:14:59 AM CET Unlocking the screen
Wed 05 Feb 2020 12:20:00 AM CET Locking the screen
Wed 05 Feb 2020 12:20:10 AM CET Unlocking the screen
Wed 05 Feb 2020 12:25:10 AM CET Locking the screen

According to log, the screen is locked for 9 seconds, then it unlocks and waits for 5 mins for autolock to run the lock script again.

When you come between the "unlocking screen" and "locking the screen", you still have to type in your password, so the screen is not really "unlocked". But the commands following i3lock -n are executed

NOTE: the actual command I use to lock the screen is

i3lock -c 000000 -i "screenbg.png" -n

but I assumed this information is irelevant

Expected Behavior

any commands following i3lock -n should be executed after the screen is trully unlocked.

Reproduction Instructions

See Current behavior

Environment

Output of i3lock --version:

i3lock: version 2.11.1 © 2010 Michael Stapelberg

[stapelberg]

Is this issue reproducible without xautolock? I use i3lock’s -n feature all the time and it works fine for me.

[chorcheus]

Is this issue reproducible without xautolock? I use i3lock’s -n feature all the time and it works fine for me.

No, the issue occurs to me only when I use it with xautolock. However, usage of xautolock with i3lock is quite common and imho i3lock -n feature should work no matter which software used with it. Thx.

[stapelberg]

I can’t reproduce this.

I copied your shell script and ran xautolock -locker lock.sh -time 1. On my machine, I see “Locking the screen” in the log file, and the “Unlocking the screen” line only appears once I type my password into i3lock.

Can you elaborate on how to trigger the issue?

Can you change your script to run i3lock with --debug, redirect the output to the log file (i3lock … >>/tmp/lock.log 2>&1), and provide the log (change your password beforehand)?

[chorcheus]

i3log.txt

Here it is. FYI, though it's so huge, this log is from one lock/unlock session. I put ... on lines where the password is entered.

Strangely this happens mostly during the night. I suppose xautolock triggers some action after each interval (I set 5 mins for xautolock), which might be issue of xautolock, but I suppose i3lock -n should ignore it. The main observable issue which bothers me is the fact that my screen is not turned off as it should be with xautolock.

This is the log file from before, it goes on and off all night, although not truly unlocking the screen:

Fri 21 Feb 2020 09:33:27 AM CET ::: Locking the screen
Fri 21 Feb 2020 09:33:36 AM CET ::: Unlocking the screen
Fri 21 Feb 2020 09:38:36 AM CET ::: Locking the screen
Fri 21 Feb 2020 09:38:45 AM CET ::: Unlocking the screen
Fri 21 Feb 2020 09:43:46 AM CET ::: Locking the screen
Fri 21 Feb 2020 09:43:56 AM CET ::: Unlocking the screen
Fri 21 Feb 2020 09:48:56 AM CET ::: Locking the screen
Fri 21 Feb 2020 09:49:05 AM CET ::: Unlocking the screen
Fri 21 Feb 2020 09:54:06 AM CET ::: Locking the screen
Fri 21 Feb 2020 09:54:15 AM CET ::: Unlocking the screen
Fri 21 Feb 2020 09:59:16 AM CET ::: Locking the screen
Fri 21 Feb 2020 09:59:25 AM CET ::: Unlocking the screen
Fri 21 Feb 2020 10:04:26 AM CET ::: Locking the screen
Fri 21 Feb 2020 10:04:35 AM CET ::: Unlocking the screen
Fri 21 Feb 2020 10:09:35 AM CET ::: Locking the screen
Fri 21 Feb 2020 10:09:44 AM CET ::: Unlocking the screen
Fri 21 Feb 2020 10:13:11 AM CET ::: Unlocking the screen

[stapelberg]

Ah, I think I have an idea of what’s going on:

Note how the timestamps between Locking…Unlocking are 10 seconds. In your i3lock debug log, I see a lot of “i3lock: Cannot grab pointer/keyboard” messages.

i3lock tries to grab the pointer and keyboard for 10 seconds before giving up. What you’re seeing in your log is not i3lock successfully locking the screen, but i3lock giving up on locking the screen. If you check the exit code of the process, you can make your wrapper script print a more appropriate message when that happens.

Now, as to why i3lock doesn’t succeed, that’s hard to tell. It could be that you have a context menu open accidentally (prevents grabbing to work), or some other application (e.g. gtk pinentry) has grabbed your server. You can run xdotool key XF86LogGrabInfo to list the current grabs into /var/log/Xorg.0.log (or whereever your X server log file is located) to shed some light on this.

[PRESFIL]

Is this issue reproducible without xautolock?

I can reproduce this with xss-lock, loginctl lock-session and xmonad instead i3.

I think the problem is that with or without -n/--nofork, i3lock creates a i3lock child process, or I don't quite understand the meaning of this option. manpage doesn't explain it too well, just says there won't be a fork:

i3lock forks, so you can combine it with an alias to suspend to RAM (run "i3lock && echo mem > /sys/power/state" to get a locked screen after waking up your computer from suspend to RAM) ... Don't fork after starting.

It's not clear if there should be 2 processes without -n/--nofork. In any case, I see i3lock with a child i3lock.

[stapelberg]

I think the problem is that with or without -n/--nofork, i3lock creates a i3lock child process, or I don't quite understand the meaning of this option. manpage doesn't explain it too well, just says there won't be a fork:

No, this is not a problem.

i3lock always creates one child process for preventing the lock screen window from being obscured by another window.

What the --nofork option controls is whether the main i3lock process itself forks and detaches from its controlling terminal.

You can see the difference by running i3lock && date and i3lock -n && date. In the first case, you’ll see the date/time of i3lock starting, in the second case, you’ll see the date/time of i3lock exiting.

[stapelberg]

Closing because of inactivity.