Closed chorcheus closed 2 years ago
Is this issue reproducible without xautolock? I use i3lock’s -n feature all the time and it works fine for me.
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.
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)?
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
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.
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
.
I think the problem is that with or without
-n/--nofork
,i3lock
creates ai3lock
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.
Closing because of inactivity.
I'm submitting a…
Current Behavior
When running
while lockscript.sh looks like:
The file
lock.log
looks like this: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 executedNOTE: the actual command I use to lock the screen is
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
: