[SOLVED] System freezes after sleep since update

bricknumber5 · 2024-06-20 15:10:47

Since I updated my machine yesterday the system now becomes completely unresponsive to input after closing the lid, requiring a hard-shutdown.

I saw that there was a systemd update with an associated news file when updating, so I looked at it and found this section:

        * The behavior of systemd-sleep and systemd-homed has been updated to
          freeze user sessions when entering the various sleep modes or when
          locking a homed-managed home area. This is known to cause issues with
          the proprietary NVIDIA drivers. Packagers of the NVIDIA proprietary
          drivers may want to add drop-in configuration files that set
          SYSTEMD_SLEEP_FREEZE_USER_SESSIONS=false for systemd-suspend.service
          and related services, and SYSTEMD_HOME_LOCK_FREEZE_SESSION=false for
          systemd-homed.service.

Indeed, running

systemctl sleep

also causes the system to become completely unresponsive to input.

That sounds like the culprit. Based on the recommendations there I tried using

systemctl edit <unit>

to add the first line to drop in files for systemd-suspend.service, nvidia-suspend.service, and systemd-suspend-then-hibernate.service and to add the second line to systemd-homed.service.

This didn't fix the problem.

The advice, of course, is targeted at packagers of the NVIDIA proprietary drivers who presumably know more than I do about this.

I don't know what the security benefits of this systemd feature are, but I don't particularly care for them (since I always enable my lock screen before sleeping, anyway, except for testing purposes recently to verify it wasn't the problem) I'd be quite happy to disable this feature entirely.

I did some searching but I couldn't find anything that was clearly helpful.

I've temporarily worked around the problem by adding

HandleLidSwitch=ignore

to /etc/systemd/logind.conf but this just suppresses sleep mode altogether, it would be nice to have a functional sleep mode.

Other information which might be relevant: I'm using xmonad, launched directly using exec startx in my .bash_profile (which itself runs exec xmonad), on an HP-Omen laptop. Since the news item mentions the nvidia drivers I'm using nvidia[-lts], nvidia-utils, and mesa none of which I recall configuring. (I've verified the problem occurs in both linux and linux-lts)

My suspicion is that this isn't actually a driver problem, but it definitely seems like an issue with this new feature.

If there's a way to just disable this feature that sounds like the easiest solution, (maybe there's a different file I should set those switches in?) but other suggestions that give me a sleep mode that isn't totally worthless would be fine as well.

Last edited by bricknumber5 (2024-06-21 04:07:26)

gromit · 2024-06-20 21:21:10

I have posted this as a feature request: https://gitlab.archlinux.org/archlinux/ … -/issues/9

Maybe you can also look into bisecting the systemd issue if you find the time if the above change does not fix it for you

bricknumber5 · 2024-06-21 04:05:48

From reading the commit linked to the issue you sent, I realized what I did wrong trying to apply the drop-in files.

I wrote

SYSTEMD_SLEEP_FREEZE_USER_SESSIONS=false

and equivalent for the other one, when I needed to write

[Service]
Environment="SYSTEMD_SLEEP_FREEZE_USER_SESSIONS=false"

and equivalent instead.

I probably should have known but I'm not used to configuring systemd files and the NEWS file is clearly intended for an audience of those with experience.

Doing this fixed the issue and my sleep works now!

Thanks

enbQao · 2024-06-25 19:26:17

I know this is [SOLVED], but I haven't found another thread regarding this new systemd "feature".
This also has the effect that it prevents screenlockers (on i3, sway, etc.) from firing up before suspending, so when you resume, the unblocked screen is shown for a few moments before it locks.
I was wondering, does anyone know what the "proper" way of dealing with this is?
I think just disabling this new systemd-feature does not seem like the right solution, since the above (screenlocker on i3, sway, etc.) is a pretty common use-case and they wouldn't add a new feature that breaks a common use-case, or would they?

seth · 2024-06-25 20:46:44

I think just disabling this new systemd-feature does not seem like the right solution

Why not?

they wouldn't add a new feature that breaks a common use-case, or would they?

gromit · 2024-06-25 21:01:14

I think there also is a third option:
1. Debug the issue
2. Write up a nice bugreport
3. Maybe see it being fixed for everybody

seth · 2024-06-25 21:12:41

See the release notes posted by the OP - upstream is fully aware of the situation and suggests to disable the feature with nvida.

=> https://github.com/systemd/systemd/issues/33083

Though https://github.com/systemd/systemd/issu … 2142473011 and other comments suggest that this is not limited to "nvidia closed source crap" which is an assumption that wrt https://github.com/systemd/systemd/issu … 2182834298 was perhaps based on the cgroup relation and the relevant issues existing between nvidia 550xx and (afaict still exclusively systemd)

An interesting test might be whether this is an issue w/ the 535xx drivers as well.

archdub · 2024-06-28 00:32:02

I updated to systemd 256 and got the issue of sleeping causing hanging. Like many I am using a proprietary nvidia driver, nvidia-470xx-utils from AUR. I am also using a kernel from AUR, linux-lts61, because sleep does not work well on my 11 years old MSI board with both linux and linux-lts.

For now the workaround of downgrading systemd to 255.7 solved my issue, next week I will look at some other solution.

The above was on my home desktop. I also run Arch at work on a Linux desktop with Intel graphics and systemd 256 works fine there.

proycon · 2024-06-28 09:49:12

I ran into this issue as well on systemd 256 on a Lenovo Thinkpad X1 Nano laptop. Wayland compositors (Hyprland, sway, river) freeze after resume, changing vt's no longer works either. Not using any nvidia drivers. Downgrading systemd to 255 solves it.

Creating a drop-in config /etc/systemd/system/systemd-suspend.service.d/disable_freeze_user_session.conf with the following also solves it for systemd 256:

[Service]
Environment="SYSTEMD_SLEEP_FREEZE_USER_SESSIONS=false"

enbQao · 2024-06-29 11:05:17

For me, another weird issues popped up. The system immediately suspends after the first resume from suspend (yes, in this order).
So when I suspend and wake the system, it goes to suspend again automatically and I have to wake it another time.
Does anyone else have this issue too?

EDIT: My bad. I copied the entire unit file into the overwrite.conf, which seems to have triggered this behaviour.

Last edited by enbQao (2024-06-29 11:26:17)

Arch Linux

#1 2024-06-20 15:10:47

[SOLVED] System freezes after sleep since update

#2 2024-06-20 21:21:10

Re: [SOLVED] System freezes after sleep since update

#3 2024-06-21 04:05:48

Re: [SOLVED] System freezes after sleep since update

#4 2024-06-25 19:26:17

Re: [SOLVED] System freezes after sleep since update

#5 2024-06-25 20:46:44

Re: [SOLVED] System freezes after sleep since update

#6 2024-06-25 21:01:14

Re: [SOLVED] System freezes after sleep since update

#7 2024-06-25 21:12:41

Re: [SOLVED] System freezes after sleep since update

#8 2024-06-28 00:32:02

Re: [SOLVED] System freezes after sleep since update

#9 2024-06-28 09:49:12

Re: [SOLVED] System freezes after sleep since update

#10 2024-06-29 11:05:17

Re: [SOLVED] System freezes after sleep since update

Board footer