Repository navigation
user session fails to resume from suspend when user is using NFS or KVM #33083
Description
Activity
Is this reproducible? Or a one-off? Did you reboot after upgrading and before suspending?
yes, i did repeat it. it happened once, i shut the system down, then i booted it again (after stumbling into and working around https://bugs.debian.org/1071592, ugh), and then i suspended it again. The same behavior happened after resuming from sleep again (no response from anything but the power button). So i rebooted again, and at this point, i have not put the machine to sleep again yet, because i'm trying to actually get other work done ( 🤯 !), and don't want to keep enduring the interruptions. I will let you know if i have the same issue yet again after the next time i suspend the machine.
It would be great if you could please try one more time, this time with logind and systemd with debug level (systemctl log-level debug and systemctl service-log-level systemd-logind debug), and attach the corresponding journal here
Some users in Debian CN group encountered similar timeout issues. My guess is that the FREEZE_BUS_CALL_TIMEOUT is too short, will submit a patch.
Is there any weird software in play here? i.e. nvidia closed source crap or something like that?
- added 5 commits that reference this issue
on May 30, 2024 99 remaining items
When will the fix affect ? I'm literally on Arch Linux and experiencing this everyday.
When will the fix affect ? I'm literally on Arch Linux and experiencing this everyday.
should already be fixed. What kernel version are you using?
When will the fix affect ? I'm literally on Arch Linux and experiencing this everyday.
should already be fixed. What kernel version are you using?
For me, it also looks like it became "unfixed", as it did use to work. I'm on Debian Testing with 6.12.11 from Debian's repos. I haven't yet tested compiling e.g. 6.13 from sources and I didn't check if the environment variable still does its trick. Also, it doesn't seem to happen every time, so it's a lot less frequent now. But I just had the same issue again. Putting into suspend failed with
Jan 31 12:04:28 systemd-sleep[13319]: Failed to freeze unit 'user.slice': Connection timed out Jan 31 12:04:28 kernel: PM: suspend entry (s2idle) Jan 31 12:04:28 systemd-sleep[13319]: Performing sleep operation 'suspend'... Jan 31 12:04:28 kernel: Filesystems sync: 0.031 seconds Jan 31 12:04:48 kernel: Freezing user space processes Jan 31 12:04:48 kernel: Freezing user space processes failed after 20.004 seconds (1 tasks refusing to freeze, wq_busy=0): Jan 31 12:04:48 kernel: task:kate state:D stack:0 pid:11885 tgid:11885 ppid:2800 flags:0x00004006 Jan 31 12:04:48 kernel: Call Trace:Followed by a long list of Kernel messages.
Experiencing the same on nixos using kernel 6.12.11 and systemd 257.2
PM: suspend entry (s2idle) Filesystems sync: 0.017 seconds Freezing user space processes nfs: server tower not responding, still trying nfs: server tower not responding, still trying nfs: server tower not responding, still trying Freezing user space processes failed after 20.001 seconds (2 tasks refusing to freeze, wq_busy=0): task:.beet-wrapped state:D stack:0 pid:79582 tgid:79578 ppid:44023 flags:0x00000006 Call Trace: <TASK> __schedule+0x3b3/0x12d0 schedule+0x27/0xf0 io_schedule+0x46/0x70 folio_wait_bit_common+0x132/0x320 ? __pfx_wake_page_function+0x10/0x10 filemap_get_pages+0x6d4/0x700 filemap_read+0xf0/0x380 ? terminate_walk+0x61/0x100 nfs_file_read+0x77/0xb0 [nfs] vfs_read+0x2a7/0x380 ksys_read+0x6d/0xf0 do_syscall_64+0xb7/0x210 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f23fbd0c48c RSP: 002b:00007f23f8afe180 EFLAGS: 00000246 ORIG_RAX: 0000000000000000 RAX: ffffffffffffffda RBX: 000000000da95d10 RCX: 00007f23fbd0c48c RDX: 0000000000100000 RSI: 00007f23f414af50 RDI: 0000000000000004 RBP: 00007f23f8aff630 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 000000000ce90950 R13: 00007f23f414af50 R14: 0000000000000004 R15: 000000000d09ea1a </TASK>I'm running into the same problem as described by OP. I'm on Manjaro Linux with 6.1.119 kernel
For the KVM issue -- your distro kernel needs backport of
d96c77bd4eeba ("KVM: x86: switch hugepage recovery thread to vhost_task")(v6.1.119 doesn't have it AFAICS).
Suspected NFS is another cause which wasn't examined yet.
I also just ran into this on 6.6.74; suspending while a KVM was running.
No interesting kernel logs to go with it and not even anything in systemd apart from these two lines after I attempted to start a new session because my current one froze:
Feb 07 18:23:13 THESEUS systemd-logind[1094]: New session 4 of user atemu. Feb 07 18:23:13 THESEUS systemd[1]: Started Session 4 of User atemu. Feb 07 18:23:13 THESEUS systemd[1]: session-2.scope: Cannot realize cgroup for frozen unit. Feb 07 18:23:13 THESEUS systemd[1]: Failed to realize cgroups for queued unit session-2.scope, ignoring: Device or resource busy Feb 07 18:23:13 THESEUS systemd[1]: user-132.slice: Cannot realize cgroup for frozen unit. Feb 07 18:23:13 THESEUS systemd[1]: Failed to realize cgroups for queued unit user-132.slice, ignoring: Device or resource busy Feb 07 18:23:35 THESEUS systemd[1]: Started Getty on tty3.- Reacted by Michal KoutnýReacted by Erik Quaeghebeur
Which LTS kernels has this been backported to?
Maybe it should not be enabled by default on broken kernels?
I have again problems with putting my system to sleep since 2 days:
May 18 06:49:25 archlinux systemd-logind[639]: Suspending... May 18 06:49:25 archlinux systemd[1]: Reached target Sleep. May 18 06:49:25 archlinux systemd[1]: Starting System Suspend... May 18 06:49:25 archlinux systemd[1]: user-0.slice: Unit now frozen-by-parent. May 18 06:49:25 archlinux systemd[1]: session-1.scope: Unit now frozen-by-parent. May 18 06:49:25 archlinux systemd[1]: session-2.scope: Unit now frozen-by-parent. May 18 06:49:25 archlinux systemd[1]: user.slice: Unit now frozen. May 18 06:49:25 archlinux systemd[1]: user-1000.slice: Unit now frozen-by-parent. May 18 06:49:25 archlinux systemd[1]: user@1000.service: Unit now frozen-by-parent. May 18 06:49:25 archlinux systemd-sleep[23135]: Successfully froze unit 'user.slice'. May 18 06:49:25 archlinux systemd-sleep[23135]: Performing sleep operation 'suspend'... May 18 06:49:25 archlinux kernel: PM: suspend entry (s2idle) May 18 06:49:25 archlinux kernel: Filesystems sync: 0.024 seconds May 18 06:49:26 archlinux kernel: Freezing user space processes May 18 06:49:26 archlinux kernel: Freezing user space processes completed (elapsed 0.001 seconds) May 18 06:49:26 archlinux kernel: OOM killer disabled. May 18 06:49:26 archlinux kernel: Freezing remaining freezable tasks May 18 06:49:26 archlinux kernel: Freezing remaining freezable tasks completed (elapsed 0.001 seconds) May 18 06:49:26 archlinux kernel: printk: Suspending console(s) (use no_console_suspend to debug) May 18 06:49:26 archlinux kernel: wlp50s0: deauthenticating from X by local choice (Reason: 3=DEAUTH_LEAVING) May 18 06:49:26 archlinux kernel: usb usb3: PM: dpm_run_callback(): usb_dev_suspend returns -16 May 18 06:49:26 archlinux kernel: usb usb3: PM: failed to suspend async: error -16 May 18 06:49:26 archlinux kernel: PM: Some devices failed to suspend, or early wake event detected May 18 06:49:26 archlinux kernel: iwlwifi 0000:aa:00.0: Failed to create debugfs directory under (efault) May 18 06:49:26 archlinux kernel: OOM killer enabled. May 18 06:49:26 archlinux kernel: Restarting tasks ... done. May 18 06:49:26 archlinux kernel: random: crng reseeded on system resumption May 18 06:49:26 archlinux iwd[14748]: Received Deauthentication event, reason: 3, from_ap: false May 18 06:49:26 archlinux iwd[14748]: event: disconnect-info, reason: 3 May 18 06:49:26 archlinux iwd[14748]: event: state, old: connected, new: disconnected May 18 06:49:26 archlinux iwd[14748]: event: state, old: disconnected, new: autoconnect_quick May 18 06:49:26 archlinux systemd-networkd[14737]: wlp50s0: Lost carrier May 18 06:49:26 archlinux systemd-networkd[14737]: wlp50s0: DHCP lease lost May 18 06:49:26 archlinux systemd-timesyncd[14730]: Network configuration changed, trying to establish connection. May 18 06:49:26 archlinux kernel: PM: suspend exit May 18 06:49:26 archlinux kernel: PM: suspend entry (s2idle) May 18 06:49:26 archlinux bluetoothd[5277]: Controller resume with wake event 0x0 May 18 06:49:26 archlinux kernel: Filesystems sync: 0.001 seconds May 18 06:49:27 archlinux kernel: Freezing user space processes May 18 06:49:27 archlinux kernel: Freezing user space processes completed (elapsed 0.001 seconds)SYSTEMD_SLEEP_FREEZE_USER_SESSIONS=falseseams to fix it for now. Has anyone else the same problem again?I am pretty sure it started with
systemd 257 (257.5-3-arch).No, but I use some scripts which setups namespaces with bwrap.
I also have some vms running with qemu.
systemd version the issue has been seen with
256~rc3-2
Used distribution
debian unstable
Linux kernel version used
6.7.12-amd64
CPU architectures issue was seen on
x86_64
Component
systemd
Expected behaviour you didn't see
I put my machine to sleep, while a user session was running, with a graphical wayland environment (
sway, locked withswaylock). Then i opened the lid to resume use. The machine woke up, butswaylockwasn't active any more, and i couldn't evenctrl+alt+F2to a different VT.However, pressing the power button did start the machine's shutdown process, though it also hung.
Unexpected behaviour you saw
New to me (since upgrading to systemd 256~rc3) was the "Failed to freeze user sessions" in the journal:
and then when trying to shut down, messages about "cannot stop frozen unit":
Eventually i hard-powered down the machine (power button for ~15 seconds).
The user journal doesn't say anything about being frozen or woken back up -- it just sees normal session log action, and then a reboot.
Steps to reproduce the problem
I have not tried to replicate it in a dedicated VM or anything like that. I don't know whether there is anything special about what's happening my particular session that would make make it fail to freeze or be unfrozen.
Additional program output to the terminal or log subsystem illustrating the issue
No response