/dev/tty-1: No such file or directory

[ghost]

linux void musl sway

first time and second time work fine

then suddenly:

physlock: /dev/tty-1: No such file or directory

at first I thought it may be related to using exec sway

same problem without exec

problem persists with -d and without it

it's only buggy when physlock is executed by sway through a keybind (exec) when executing directly from terminal it appears to work

the two times it does work it always outputs:

/dev/tty0: VT_DISALLOCATE: Resource busy

no idea what's /dev/tty-1 about because it never existed to begin with, there's a bunch of tty's in /dev/ without slashes.

when executed in terminal often it's somewhat buggy, the terminal keeps spamming newlines after it unlocks until i press some key.

[Atemu]

On NixOS 20.03 this happens after suspending the system with sway running

[cp289]

On Arch Linux I can reproduce this issue by performing the following steps.

1. Manually lock the screen in Sway (e.g. key bind, or physlock -d in a terminal)
2. Suspend the machine
3. Wake and unlock machine

Step 2 is a repeated invocation of physlock since I have the following systemd service enabled:

Description=User suspend actions
Before=sleep.target

[Service]
User=<user>
Type=forking
ExecStart=/usr/bin/physlock -dms

[Install]
WantedBy=sleep.target

After logging back in, systemctl status reveals that the above service failed with the error

physlock[515354]: physlock: /dev/tty-1: No such file or directory

At this point, ps -e | grep -c physlock shows 59 instances of physlock running. Any attempt to run physlock results in the error until these processes are killed manually with killall physlock (which also results in spamming newlines to the terminal).

I haven't noticed this issue unless I carry out the three steps above beforehand.

[Atemu]

At this point, ps -e | grep -c physlock shows 59 instances of physlock running.

Nice catch! This happens on my machine aswell.

After killing all the processes, physlock actually works perfectly fine again and doesn't break on suspends anymore.

Weird...

[wizeman]

I'm running into the same issue. In my case, this seems to be triggered by me pressing the Alt+K Sway keybind to lock my screen (I've configured it to run physlock -ds). When physlock runs, it switches to another virtual terminal, but the switching causes the Alt+K keybind to remain pressed in Sway/wayland and therefore Sway runs physlock multiple times in a row.

And it seems that physlock has some kind of race condition where if you run it multiple times in a short timespan, one of the processes runs, but the others get stuck... and when the screen gets unlocked, then subsequent attempts to run physlock will fail, likely because of the other physlock processes still running in the background (even though the screen is unlocked at that point).

I have "worked around" this issue by configuring the keybind in sway with bindsym --no-repeat instead of just bindsym so that Sway doesn't start many physlock processes when I press the keybind. However, there is still a serious bug in physlock, because it should never fail to lock the screen (especially not because of a seemingly trivial issue such as this one)!