System freezes during suspend after 2024-06-13 qemu update

General system Kernel, boot, graphics & hardware
1

This looks a lot like System freezes on suspend/hibernate after update to systemd 256-3 but seems to be related to qemu.

If qemu is not running, or just the binary qemu-system-x86_64 is executed without a VM, suspend /resume function normally.

If qemu is running an active guest, the host system freezes during suspend. Last kernel message is “wlan0: disassociate from …”, after that the system is unresponsive. SysRq does not work, but may be related to my keyboard.

System information: https://0x0.st/XA96.txt

The common qemu options:

QEMU_OPTIONS="-name $machine \
	-enable-kvm \
	$serial_redirect \
	-M q35 \
	-cpu Haswell -smp 2 \
	-m 256M \
	-device e1000,netdev=lan0 \
	-netdev user,id=lan0,hostfwd=::8088-:8080,hostfwd=::8080-:80,hostfwd=::8022-:22,hostfwd=::8023-:23 "

Temporary workaround: downgrade via eos-shifttime to 2024-06-12 and wait for a new qemu version.

If anyone has an idea how to troubleshoot this issue, suggestions are welcome.

2

Incremental updates and testing the result brought me to the conclusion that the systemd update from 255 → 256 was responsible for the suspend failures, after all. In retrospect, the systemctl Journal started to show “Failed to freeze unit ‘user.slice’” errors after the failed update on June 19.

Github has two issues that highlight this bug.

33626 might well be the root cause of this failure; the proposed patch has not yet appeared in any kernel.

33083 explains what happened [1]

Yeah, that’s expected. Because we started freezing user sessions in v256. Yet I think the real problem lies in the kernel.

and proposes a possible fix [2].

# systemd_dir=/etc/systemd/system/systemd-suspend.service.d
# mkdir -p $systemd_dir
# touch $systemd_dir/disable_freeze_user_session.conf
# cat << EOF > $systemd_dir/disable_freeze_user_session.conf
[Service]
Environment="SYSTEMD_SLEEP_FREEZE_USER_SESSIONS=false"
EOF

Not tested yet, I just put systemd updates on hold.

[1] https://github.com/systemd/systemd/issues/33083#issuecomment-2188836347
[2] https://github.com/systemd/systemd/issues/33083#issuecomment-2196565757

3

Thanks for your research.

So it’s the same problem as with NVIDIA graphics (which in my case is optional because I both have a dedicated NVIDIA card as well as a builtin AMD GPU, and I can switch these).

But the thing is I was also experiencing this when using AMD graphics, which makes clear that the issue is much larger than just NVIDIA related.
It’s quite frustrating to see my system entirely hang with a black screen after walking away while it was running a virtual machine too.

In my case I am running vanilla Arch Linux, but the same things currently apply, running systemd version 256+.

I am now also considering that SYSTEMD_SLEEP_FREEZE_USER_SESSIONS=false setting, because if there are multiple ways those problems occur, what more is possible? :unamused:

However, for QEMU I did solve it in another way (I really don’t trust sleep and hibernation generally actually), I changed my shell script to run QEMU this way:

#!/bin/sh
GDK_BACKEND=x11 \
GDK_SCALE=1 \
systemd-inhibit \
--what='sleep:handle-power-key:handle-suspend-key:handle-hibernate-key:handle-lid-switch' \
--why='Running virtual machine' \
qemu-system-x86_64 \
	-enable-kvm \
	-smp 8 \
	-m 8G \
	-cpu host \
(...)

systemd-inhibit is a systemd tool to suppress the sleep while the program (QEMU in this case) you specify to run with it is running.

(Note that the 2 environment variables that I have set are unrelated, these solve another problem, namely that running under Wayland while fractional scaling is used results in pixel blur with QEMU, so XWayand is a need for me)

4

Thank you for the systemd-inhibit snippet, it might be useful at some time.

The SYSTEMD_SLEEP_FREEZE_USER_SESSIONS environment variable is currently in place.

$ journalctl -b 0 -u systemd-suspend

now contains a warning:

User sessions remain unfrozen on explicit request ($SYSTEMD_SLEEP_FREEZE_USER_SESSIONS=0).
This is not recommended, and might result in unexpected behavior, particularly in suspend-then-hibernate operations or setups with encrypted home directories.

The kernel freezes tasks anyway (just not initiated by systemd), the systemd warning relates to scenarios that are out of scope for me, so I might keep this workaround indefinitely.

5

There was a qemu update today, not sure if this is still an issue or not.

6

The change log does not mention this topic. Version 9.1 is not yet available in the repositories:

$ pacman -Ss qemu-full
extra/qemu-full 9.0.2-1
A full QEMU setup

A fix for this issue will probably have to come from systemd or the Linux kernel.

1 Like