red screen of death after unlocking

[primalmotion]

Please fill out the following:

• Sway Version: sway version 1.8-dev-251a648e (Jun 1 2022, branch 'master')

• Debug Log: https://gist.github.com/primalmotion/c4d39ea0879cb7559dafc12fa0f58718

• Description: Randomly (but pretty often) when I wake the machine up, I can enter my password from swaylock to unlock the screen, then all monitors are red (literaly completely red) and sway, while still running, does not respond to anything. I must switch to another tty, login, kill sway and restart it. This started to happen a few weeks ago

[emersion]

This happens when swaylock crashes.

That log is incomplete and only contains ERROR messages.

[primalmotion]

yeah it's my classic log.. I've enabled debug and will run in that mode for a while until it happens again

[primalmotion]

that did not take long

https://gist.github.com/primalmotion/94cd2492896568363ea7358c5bac6643/

[emersion]

Can you try to update sway+wlroots to latest commit?

The end of the log says the unlock is successful, but is followed by a EBUSY:

00:02:20.348 [ERROR] [wlr] [backend/drm/atomic.c:71] connector DP-2: Atomic commit failed: Device or resource busy
00:02:20.348 [DEBUG] [wlr] [backend/drm/atomic.c:75] (Atomic commit flags: PAGE_FLIP_EVENT | ATOMIC_NONBLOCK)
00:02:20.827 [DEBUG] [sway/lock.c:88] session unlocked

[primalmotion]

Sure let me upgrade. I'll report if it happens again

[primalmotion]

ok after multiple fights with other issues, I was able to test latest master. The issue still happens

[ldelossa]

experiencing this as well, reliably reproducible by locking the screen, hoping to another tty, killing swaylock, and coming back to Sway's tty.

[primalmotion]

Yeah I noticed this way to reproduce too. I found out because swaylock was not responding. switch to another tty, and killed it. red screen. From what I understand, the red screen is basically here to prevent unlocking the laptop even if the swaylock process dies. So it seems the actual problem is not the red screen, but the fact that swaylock crashes one way or another without "releasing" the session lock

[primalmotion]

I haven't seen this issue in a while now (seems it's been 2 weeks)

[primalmotion]

obviously I had to write a comment just before it actually happened again.

[nurelin]

It also happens to me from times to times after suspending, usually putting it back to sleep and waking it up fixes it.

[primalmotion]

interesting. I'll give it a try next time. I noticed that this seems to happen when I wake up my system, when it has an attached external monitor, and enter my password + enter while that monitor is still waking up.

[emersion]

Please obtain a stack trace for swaylock.

[alxchk]

I have this screen of death when system is under high load, one display is off and one display is on. However I'm not able to reproduce it withing some reasonable period of time. Running weeks with debug looks seems not to be good idea..

[ljupchokotev]

I can reproduce this each time my laptop comes out of sleep and I have my external monitors connected. Both of the monitors will just have a red screen and I have to switch to a tty and do a systemctl suspend a few times to get rid of it.

Today I also got it on my laptop without any external monitors. Swayidle triggered swaylock, I saw the lockscreen for a second and then it turned to the red screen on my laptop screen. But this doesn't seem to be reproducible easily.

Here is a stack trace https://gist.github.com/ljupchokotev/22cf9ef0163d7d865aa1f7c1c734cb5f.

[bigfreak85]

same problem here. I have a yubikey and do some udev rules to automaticly lock the screen https://kliu.io/post/yubico-magic-unlock/ if i use kill anytime the red-screen appears. I have downgraded to 1.5 fixed it for me... seems to be a Security improvment but how can i do the automatic unlock with swaylock 1.6?

[scippio]

:warning: !EDIT: "official" package from Archlinux community (swaylock version 1.7) works fine! :warning:

After yesterday updates of my Archlinux my swaylock go to red screens too...

[2023-01-04T12:38:48+0100] [ALPM] upgraded wlroots (0.15.1-6 -> 0.16.1-2)
[2023-01-04T12:38:48+0100] [ALPM] upgraded sway (1:1.7-10 -> 1:1.8-3)

I'm using this command: swaylock -F -c 000000 -k sway version 1.8 swaylock version v1.6.10-4-ga1cf657 (Jan 5 2023, branch 'master')

btw I'm using this version: https://github.com/jirutka/swaylock-effects

[asas1asas200]

Same issue

[kenshaw]

Same issue as @scippio -- just reporting here. Downgrading sway and wlroots has fixed the issue temporarily. Had the same version changes as scippio did.

[bigfreak85]

same problem here. I have a yubikey and do some udev rules to automaticly lock the screen https://kliu.io/post/yubico-magic-unlock/ if i use kill anytime the red-screen appears. I have downgraded to 1.5 fixed it for me... seems to be a Security improvment but how can i do the automatic unlock with swaylock 1.6?

with the latest Version you can send a USR1 Signal to the process to stop it. So yubikey unlock works now with some modifications (pkill -USR1 swayidle)

[sydfouzan]

warning !EDIT: "official" package from Archlinux community (swaylock version 1.7) works fine! warning

After yesterday updates of my Archlinux my swaylock go to red screens too...

[2023-01-04T12:38:48+0100] [ALPM] upgraded wlroots (0.15.1-6 -> 0.16.1-2)
[2023-01-04T12:38:48+0100] [ALPM] upgraded sway (1:1.7-10 -> 1:1.8-3)

I'm using this command: swaylock -F -c 000000 -k sway version 1.8 swaylock version v1.6.10-4-ga1cf657 (Jan 5 2023, branch 'master')

btw I'm using this version: https://github.com/jirutka/swaylock-effects

Agree with OP. Same error on my side, even firefox crashes on external monitor with scaling different than 1.0.

[deralmas]

I can replicate this exact issue on the current master (2c0f68b) consistently under high load. I tried logging version 1.8 with --debug --verbose and there was nothing conclusive. Perhaps a [INFO] [wlr] [wayland] error in client communication (pid 27411), but nothing more, even considering whether that pid was actually swaylock.

Sorry for the kinda vague report, I don't have much time to test, so I'll have to rollback to 1.7 for now I guess.

Edit: Can confirm that rollbacking to 1.7 fixed the issue. I must also note that 1.8 broke alpha too in the lockscreen, while 1.7 works with transparent lockscreens without any trouble.

[hungshihhan]

I ran into the same issue after a system upgrade on gentoo. Rolling swaylock-effects back to 1.6.3 (but keeping other packages updated) the problem disappears.

[feschber]

The problem seems to be with swaylock-effects and swaylock-fancy only. The default swaylock works flawlessly

[prometheanfire]

I've had this issue with swaylock only (I don't have any effects or fancy module installed).

[deralmas]

@prometheanfire according to my previous testing, I can agree. Even vanilla swaylock presents this issue.

[deralmas]

Updating to swaylock 1.7.2 fixed the issue.

[kj]

Updating to swaylock 1.7.2 fixed the issue.

Are you sure about that? I had a red screen yesterday and according to my package manager I installed 1.7.2 on 29 January.

Edit: For the full context, I have a systemd user service that runs:

ExecStart=/usr/bin/swayidle -w \
	before-sleep 'swaylock -f -c 000000' \
	timeout 300 'swaylock -f -c 000000'

I have a Kanshi profile for my external monitor which runs (when plugged in):

exec sh -c 'pkill -USR1 swaylock; sleep 0.1; systemctl --user stop swayidle'

[blastrock]

I still have the issue here with sway 1.8 and swaylock 1.6.11 when I wake my laptop from hibernation.

I have no idea about the cause, but I have found a workaround to recover the session. Open another TTY and run

WAYLAND_SESSION=wayland-1 swaylock

Now go back to the red screen sway which is now locked. Unlock it with your password, and your session is recovered!

[deralmas]

@kj

Are you sure about that? I had a red screen yesterday and according to my package manager I installed 1.7.2 on 29 January.

For some bizarre reason I didn't read this, sorry.

Yeah, I'm pretty sure. I've been using the latest swaylock for a month without any issue.

@blastrock have you tried to update your version of swaylock?