@MasterSergius Of course you can always switch to another TTY. But other TTYs are unusable unless you logged in to them. And if you did that, you should lock them (or log out of them).

There's nothing i3lock can do here as this keybinding isn't under its control. That keybinding comes straight from the kernel.

from i3lock.

Switching TTYs happens in the kernel, i3lock cannot prevent that from happening as the keys are intercepted by the kernel. You can do that with Ctrl+Alt+F{n} to get to the n-th TTY. Where your current session is running depends a little bit on your setup.

from i3lock.

I’m not yet convinced this is an i3lock problem. Killing i3lock to see whether the problem disappeared would’ve been a really valuable test.

Issues with your graphics driver and/or x server could also manifest themselves like what you’re describing.

For completeness, which i3lock version are you using?

from i3lock.

i3lock version: 2.7

from i3lock.

Very similar problem - occurs only on two monitors. If I lock system with i3lock, I still can switch to another tty (one of 1-6) and it is unlocked! Just console, where I logged in, so anyone can access my computer in such way.

from i3lock.

I had this same problem. I changed to another TTY and killed i3lock, but when I switched back, the verifying screen was still there. I couldn't do anything except kill i3wm to end the session and re-login.

from i3lock.

I am using i3lock version 2.6.

from i3lock.

Another data point - two monitors and i3lock 2.8-1 (from Debian testing), and I was not unable to unlock my system today. However, after switching to another tty and killing i3lock, I was still stuck at the lock screen. Based on @stapelberg 's earlier comment, I believe this indicates that it's not an i3lock problem, at least, not in my case. (I obviously can't speak for anyone else).

from i3lock.

It's been a while, but it's the first time I've been able to replicate the issue. Indeed after I killed i3lock and xautolock the verify screen persisted. Given that behaviour I'm inclined to believe this isn't an i3lock problem.

i3lock version: 'version © 2010 Michael Stapelberg'
i3 version: i3 version 4.13 (2016-11-08) © 2009 Michael Stapelberg and contributors

I'll close this issue now, although I'd love your input on what you think might be causing this, @stapelberg.

from i3lock.

Interesting, I've just started experiencing this, oddly I think my vconsole systemd service is failing.

from i3lock.

I think I'm seeing the same problem on a system with only a single display.
Maybe once in every few hundred unlocks the screen gets stuck at "verifying...", even after killing i3lock from the TTY.
I've had this happen a few times now, over the course of a few months.
Using i3-msg to send the "restart in place" command fixed my session the last time it happened.

i3lock: version 2.9.1 (2017-06-21) © 2010 Michael Stapelberg
i3 version 4.13 (2016-11-08) © 2009 Michael Stapelberg and contributors
(Arch Linux)

from i3lock.

Possible workaround for this bug

1. Switch to another VT and log in on the console.
2. Kill the i3lock process (and confirm it worked)
3. Find the location of the i3 socket (on my system it was /run/user/<uid>/i3/ipc-socket.<pid>).
4. Start i3lock with the following command: i3-msg -s <socket-path> exec i3lock
5. Go back to your graphical VT where i3 is running
6. Now you should be able to enter your password like normally and get back to your i3 session.

What I noticed (sadly not much...)

I just hit this bug as well. After entering the password (should've been the correct password) i3lock was stuck on "verifying...". I'm using two monitors: The primary monitor of my laptop (FullHD via eDP) and a secondary FullHD monitor that mirrors my primary monitor and is connected via an USB-C to HDMI adapter. I had some other X11 issues in the past but I could fix all of them by switching to another VT (required using the SysRq keys to exit the raw mode) and than back to the graphical VT where i3 is running. Since I couldn't find anything suspicious in the X11 log I'm not sure if it's really an X11 issue. But since killing i3lock doesn't fix the problem either it probably isn't related to i3lock as well. I then continued to issue some commands with i3-msg via another VT and everything worked fine (e.g. success after issuing reload).

Could it be possible that i3lock keeps a lock on the screen (and possibly the keyboard) that prevents the i3 process from updating it or something like that?

X11 log after switching back from another VT:

X[894]: (II) AIGLX: Resuming AIGLX clients after VT switch
X[894]: (II) intel(0): switch to mode [email protected] on eDP1 using pipe 0, position (0, 0), rotation normal, reflection none
X[894]: (II) intel(0): switch to mode [email protected] on DP1 using pipe 1, position (0, 0), rotation normal, reflection none

Note: Issuing i3-msg -s <...> debuglog on might be useful but I couldn't find anything that seemed like an error or related to this bug.

from i3lock.

I can consistently reproduce this issue with a multi-monitor setup. If there is anything I can try to get some useful logs, please let me know. It will be nice to track this down to whatever program is causing this. Thanks.

from i3lock.

@JonnyMako

• Are you using i3lock 2.9.1?
• Is the issue reproducible under a new UNIX user account, i.e. without any of your dotfiles?
• Is the issue reproducible with the “vesa” driver (ruling out whichever Xorg driver you’re currently using as a culprit)?
• Is the issue reproducible with just one monitor?
• When i3lock hangs, can you attach gdb (using gdb $(which i3lock) -p $(pidof i3lock) and provide the result of backtrace full please? This requires the i3lock debugging symbols, which might be in a different package depending on your distro.

from i3lock.

changed to another TTY and killed i3lock

How do you get to another terminal if i3lock won't unlock? Are you just sshing to the machine? I am using i3 on a dual monitor setup and sometimes it won't unlock with correct password

from i3lock.

I think because i have i3 installed with xubuntu, i3lock is not allowing me to access terminal via Crtl+Alt+T or F key options. Ctrl+Alt+F1 works though.

from i3lock.