xyb3rt / physlock

Lightweight linux console locking tool
GNU General Public License v2.0
303 stars 36 forks source link

Preventing multiple physlock instances #78

Closed cdown closed 5 years ago

cdown commented 5 years ago

Hey there,

I have physlock set to run on a few conditions. For example, automatically after a timeout, when I explicitly run it, and when my laptop enters sleep. All of these work fine.

However, sometimes I notice that there are physlock instances which are running in the background, as it seems they overlapped with each other. For example, physlock already ran because the screen was idle, and then I put the computer to sleep by closing the lid. At that point, there are then two instances of physlock running. After I unlock the session, there is still one running in the background, sitting in one of the VT_WAITACTIVE ioctls:

% pgrep -x physlock
16561
% sudo cat /proc/16561/stack 
[<0>] __vt_event_wait.isra.0.part.1+0x3b/0x80
[<0>] vt_waitactive+0x70/0xc0
[<0>] vt_ioctl+0x6c9/0x1110
[<0>] tty_ioctl+0x220/0x8c0
[<0>] do_vfs_ioctl+0xa4/0x630
[<0>] ksys_ioctl+0x60/0x90
[<0>] __x64_sys_ioctl+0x16/0x20
[<0>] do_syscall_64+0x5b/0x180
[<0>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
[<0>] 0xffffffffffffffff

In fact, if one then switches to another VT than the one initially unlocked, this remaining physlock will lock the session again.

What do you think about having a lock to prevent this situation from happening? If that seems desirable to you, I'm happy to implement it. Otherwise I'm happy to just write my own wrapper, just seems more respectful to surface upstream first. :-)

mk-pmb commented 5 years ago

write my own wrapper

Before you do, consider run-one.

xyb3rt commented 5 years ago

Duplicate of #77.