You are not logged in.
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)
Offline
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
Offline
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
Offline
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?
Offline
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?
Offline
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
Offline
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.
Offline
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.
Offline
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"
Offline
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)
Offline
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.
How did you manage to downgrade systemd? Did you download all packages manually from archive.archlinux.org?
Offline
Regardless: don't. Add the override.
Offline
I know that this topic is marked SOLVED but I wanted to drop info here for anyone else searching who comes across this.
This issue does not appear to only affect proprietary NVIDIA drivers. Updating systemd on my T470 w/ intel HD 620 integrated graphics with the i915 kernel driver. The solution here works for this platform as well.
Offline
This definitely does not affect strictly NVIDIA proprietary drivers. I am running into this issue with Plasma Wayland and I use an all AMD system. I am not using AMD proprietary drivers, only the in-kernel device drivers and the Mesa drivers.
Offline
I seem to be an odd one out on this issue. The override does not work at all. Only reverting to kernel 6.10.3, systemd 255.7 and linux-firmware 20240703 restored sleep to prior functionality.
Offline
I seem to be an odd one out on this issue. The override does not work at all. Only reverting to kernel 6.10.3, systemd 255.7 and linux-firmware 20240703 restored sleep to prior functionality.
you are, for better or worse, not the only one - my amd system is also freezing after waking up post-systemctl sleep as of yesterday.
# /etc/systemd/system/systemd-homed.service.d/override.conf
[Service]
Environment="SYSTEMD_HOME_LOCK_FREEZE_SESSION=false"
# /etc/systemd/system/systemd-suspend.service.d/disable_freeze_user_session.conf
[Service]
Environment="SYSTEMD_SLEEP_FREEZE_USER_SESSIONS=false"
kernel 6.11.2, systemd 256.7.1, linux-firmware 20240909, hyprland 0.44.0-1, mesa 1:24.2.4-1
(ie all latest at time of writing)
journalctl -b -1
hyprland session logs
config files (perhaps notably hyprland.conf with relevant device.conf being ##cordelia, kansai for monitor management)
Last edited by lachlantula (2024-10-09 10:39:10)
Offline
@Shijikori is it enough if you downgrade just one of the packages?
Offline
@Shijikori is it enough if you downgrade just one of the packages?
downgrading the kernel alone to 6.10.10 seems to be enough for me. no change when downgrading systemd or firmware. so sleep on systemd 256.7.1 is working ok with that kernel version
Last edited by lachlantula (2024-10-09 10:39:57)
Offline
Does the latest mainline release candidate work for you?
sudo pacman -U https://pkgbuild.com/\~gromit/linux-bisection-kernels/linux-mainline-6.12rc2-1-x86_64.pkg.tar.zst
Offline
Does the latest mainline release candidate work for you?
sudo pacman -U https://pkgbuild.com/\~gromit/linux-bisection-kernels/linux-mainline-6.12rc2-1-x86_64.pkg.tar.zst
unfortunately not; logs read similarly (journalctl output)
Last edited by lachlantula (2024-10-09 11:03:56)
Offline
Hm, since the only thing that seems to be changing between the two behaviors is the kernel this might be a regression with the kernel. Could you open a separate thread and link it here so we can debug this there?
Offline
Same as https://bbs.archlinux.org/viewtopic.php?id=299987 ?
@lachlantula also see the 3rd link below. Mandatory.
Disable it (it's NOT the BIOS setting!) and reboot windows and linux twice for voodo reasons.
(Though there seems no parallel windows in the other thread and it would not hinge on the kernel version)
Offline
Disabling wifi and bluetooth on sleep works as workaround!
https://www.reddit.com/r/Fedora/comment … ernel_611/
I comfirmed that 6.11.2+ kernel versions have this issue and downgrading just kernel package works as well. But I found the workaround above better since you can have consistent versions.
Last edited by kolpakoa (2024-11-14 04:45:15)
Offline
EDIT: Woops, replied to the wrong post Removing my comment, but don't see a way to delete it
Last edited by keeyan (2024-11-20 22:54:02)
Offline