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]

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

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

[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.

[Riteo]

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).

[Riteo]

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

[Riteo]

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!

[Riteo]

@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?

[blastrock]

I didn't notice I didn't have the latest version! I forgot that I switched to swaylock-effects and it looks like that one is abandoned.

Anyway, I've been using the latest version of swaylock for the past week or so and I didn't have this bug anymore. A bit sad to lose the nice features of swaylock-effects, but at least my issue is fixed, thanks!

[thyeun]

@blastrock i'm not sure which version of swaylock-effects that use by you, but there was an upgrade from arch linux that upgrade the version from swaylock-effects-git r402.xxxxxxx-1 to swaylock-effects-git r416.xxxxxx-1 when you reinstall swaylock-effects again

And i'm not sure either it will solved the red screen of death or not but is solve one of the issue i facing ext_session_lock_surface_v1@21: error 0: session lock surface has never been configured. (i also facing red screen of death too)

[blastrock]

I don't use archlinux but I can't find any r416 version on AUR. The swaylock-effects-git package (r402) just seems to be based of https://github.com/jirutka/swaylock-effects whose latest version is 1.6.11, and I had the red screen with that version. I can't find that r416.

[thyeun]

@blastrock as you can see from the pic below, the aur at arch linux is r402, but once you re-install it, you will get r416

just try to re-install it again

[thyeun]

And i can start swaylock without getting RSOD any more

Below is the youtube that i can trigger the swaylock without RSOD

Here

[blastrock]

The commit hash seems to be same as the one I was using: jirutka/swaylock-effects@a7691b8, and I had RSODs with that :(

[blastrock]

Hi there, in case there are other people like me using swaylock-effects, I have made my own fork. The only thing I did on it is merge the upstream swaylock: https://github.com/blastrock/swaylock-effects-second . I didn't get the red screen of death in the last week so it might be fixed. EDIT: nevermind, got it again...

In any case, it looks like this bug is unrelated to sway, so this issue can be closed I guess...?

[Riteo]

In any case, it looks like this bug is unrelated to sway, so this issue can be closed I guess...?

@blastrock yeah, IIRC all reported cases where caused by incompatible/old swaylock versions.

[shaohme]

Using Debian trixie/testing, this happens on my setup when killing swaylock, start a wayvnc session, and trying to connect to it with a vnc client over a ssh session.

swayidle = 1.8.0-1
swaylock = 1.7.2-1
sway = 1.8.1-2

[emersion]

So there seems to be multiple unrelated issues mixed up here:

• If swaylock crashes, this will result in a red screen. Please report the swaylock bug on the appropriate issue tracker with a stack trace (note, swaylock-effects bugs are not to be reported in the swaylock issue tracker).
• If swaylock is killed, this will also result in a red screen. If what you really want is unlock the screen, you can pkill -USR1 swaylock instead.

[command-z-z]

I can find r420 version on AUR. The swaylock-effects-git package (r420) works for me and I don't have the red screen with this version any more.

[Sewer56]

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!

This didn't quite seem to work for me, however, I might aswell share what I ran across.

In my case, I was running under Hyprland and the environment variable appears to be called WAYLAND_DISPLAY.

I found this out by finding a process that started under the compositor. And reading it's environment variables under /proc/$pid/environ.

That seemed to work towards running the application, but the application would just error out, saying the screen was already locked failed to lock session -- is another lockscreen running.

In my case, swaylock was not responding to my keyboard after waking up from suspend. To lock, I originally ran systemctl suspend & swaylock. Thinking it was the natural thing to do, I killed the process. Then I was stuck.

[Andy3153]

In my case, swaylock was not responding to my keyboard after waking up from suspend. To lock, I originally ran systemctl suspend & swaylock. Thinking it was the natural thing to do, I killed the process. Then I was stuck.

Exactly the same thing I run almost all the time into. But suspending is handled by swayidle for me, but I believe it amounts to running the same command

[prometheanfire]

for me, this issue happens if oomkiller kills things, swaylock in particular

[thyeun]

After i commented till today, i will never getting RSOD any more no matter manually trigger by keyboard or let the timer set accordingly or even oomkiller, my laptop is intel gen-2 from 2008 till now.

Try follow my comment and do exactly, see will it happen again. Hope you all no more RSOD on year 2024.

[KiaraGrouwstra]

related: swaywm/swaylock#282

[blastrock]

Not sure everybody noticed but there has been a couple releases of swaylock-effects since last time: https://github.com/jirutka/swaylock-effects/tags . I upgraded a couple weeks ago and didn't get a RSOD yet, might be fixed.

[KiaraGrouwstra]

@blastrock 1.7.0.0 of swaylock-effects seems still affected.
thread over there: jirutka/swaylock-effects#57

[veganomy]

A small weird hack. It's quirky but seems to work for me.
If you use swayidle to swaylock, or hypridle to hyperlock, make sure you lock the session after the wakeup, instead of before.

swayidle -w timeout 900 'systemctl suspend' after-resume 'swaylock'

Make sure the lock command is inside after-resume instead of timeout. Ofcourse, the system might be sleeping in an insecure state. But the moment you wake it up, systemd does it's lock job without invoking any wayland bugs.