Lockscreen app dying after every suspend

Hyprland version
0.55.2

Describe your issue / feature…

Recently I have had the issue of hyprlock crashing and giving the “oopsie daisy” screen after I wake my computer up from being suspended. I was having this issue before when I had the setting for hypridle to turn off the monitors before suspending, but when I disabled it the problem went away until now. I cannot even restore my session with the commands displayed on the error screen since I am using a lua config and it gives weird lua errors that I do not understand when I try to run the commands displayed. I am on hyprlock 0.9.5 and hypridle 0.1.7. I am on Gentoo Linux. I can provide any other information needed. Thank you!

Lots of such issues with hyprlock past few months:

I’ve set hypridle to trigger swaylock instead until this stuff is sorted out.

suspend and hibernate can be one of the more fragile parts of a linux desktop because you’re essentially freezing a running session and expecting every driver, service, and graphical component to resume exactly where it left off. Most of the time it works, but when it doesnt, you end up with all sorts of different possible issues.

personally, i tend to avoid suspend and hibernate on linux desktops unless I absolutely need them. modern systems boot so quickly that I generally prefer locking the screen, turning the displays off after a period of inactivity, and letting the machine continue running then using hypridle to just shut down after a period of inactivity after that. That eliminates a whole category of wake from suspend issues. that said, I wouldnt immediately assume suspend itself is the root cause here. Since you’re getting the hyprlock “oopsie daisy” crash screen, Id be curious whether hyprlock is actually crashing on wake due to a compositor, graphics, or a session lock protocol issue rather than the suspend operation itself.

the fact that you mentioned the problem originally seemed related to monitor power management and that disabling monitor off behavior temporarily fixed it makes me suspect some sort of display reinitialization race condition during resume when the displays, compositor, and lock screen are all trying to reinitialize after wake.. if i personally were troubleshooting, id start by checking the hyprlock, hypridle, and hyprland logs immediately after reproducing the issue if possible..I’d also look at journalctl -b and any gpu related messages around the time of wake. it would also be useful to know what gpu you are using because suspend/resume behavior can vary quite a bit between drivers. im not saying suspend is definitely the culprit here, but based on what youve described, id be looking closely at what happens during the resume process rather than the lock screen configuration itself i think…

I also use hyprland + hypridle on a sometimes-docked-laptop and the close-lid to lock and suspend never worked. I never figured out to fix the race condition.
Check my post here = Recovery from zero monitors (clamshell mode setup) - #4 by zatoichi

Situation under swaylock was way worst btw

Anyway only 2 options are liveable for me so far:

  • let hypridle lock automatically after a few minutes and then suspend a bit later, then close lid
  • lock manually, and then have a button in your hypridle screen to “systemctl suspend”, then close lid

Anything else usually result in crash on resume and tty console is needed

Oh and if laptop is docked (usb-c monitor) and suspended, then i have to turn on/off my monitor a few time to wake it up, which is annoying, but usually work

@zatoichi, what does any of that have to do with the thread topic?

Start a new topic, search the bug tracker, or open a new issue if one doesn’t exist: