System sometimes irreversibly freezes when I try to suspend

kaz49 · 2025-01-15 03:44:55

Hello.

For the past couple months, I've had this problem where whenever I put my laptop to sleep, there's like a 1% chance that the system freezes completely (even sysrq+REISUB doesn't work) and I am forced to hold down the power button to reboot. The screen goes black except for the mouse pointer, which stays on screen and doesn't respond to the touchpad.
It's persisted across multiple kernel versions and I've lost a decent bit of unsaved work to this glitch, so I thought I'd ask for help.

I did a bit of digging in journalctl, and I think I might have found something...? Whenever my laptop successfully sleeps, I see the messages

kaz49-dynabook systemd-sleep[384482]: Successfully froze unit 'user.slice'.
kaz49-dynabook systemd-sleep[384482]: Performing sleep operation 'suspend'...
kaz49-dynabook kernel: PM: suspend entry (s2idle)
kaz49-dynabook kernel: Filesystems sync: 0.045 seconds
kaz49-dynabook kernel: Freezing user space processes
kaz49-dynabook kernel: Freezing user space processes completed (elapsed 0.029 seconds)
kaz49-dynabook kernel: OOM killer disabled.

But when the sleep fails, I see

kaz49-dynabook systemd-sleep[1111480]: Failed to freeze unit 'user.slice': Connection timed out
kaz49-dynabook systemd-sleep[1111480]: Performing sleep operation 'suspend'...
kaz49-dynabook kernel: PM: suspend entry (s2idle)
kaz49-dynabook kernel: Filesystems sync: 0.014 seconds
kaz49-dynabook kernel: Freezing user space processes
kaz49-dynabook kernel: Freezing user space processes failed after 20.006 seconds (1 tasks refusing to freeze, wq_busy=0):
kaz49-dynabook kernel: task:plasmashell     state:D stack:0     pid:1092  tgid:1092  ppid:794    flags:0x00004006

and and "OOM killer enabled." after a long stacktrace-looking thing.
Something to do with Plasma misbehaving, perhaps? I can't be sure though, I'm not an expert.

I have full journal logs on my disk, but I wasn't sure if posting them would be a security risk. If I should post the full journal, please do tell me to do that
Thank you in advance for your help!

seth · 2025-01-15 14:45:16

Plasma is waiting for some IO - the journal isn't supposed to contain any sensitive data (sometimes public IPv6 addresses show up), but that's not gaonna be the journal from an incident where

the system freezes completely (even sysrq+REISUB doesn't work) and I am forced to hold down the power button to reboot

because that will preclude the journal from being written to disk.

Looking at the journal to see whether there's anything generally suspcious is the best we can do out of that condition :\

kaz49 · 2025-01-17 02:20:51

I tried looking for more suspicious things in the log myself, but I'm afraid most of it is indecipherable to me.

I've posted the logs online, I'd really appreciate it if you could take a look
Log starting from when I pressed the sleep button (I hope) pastebin.com/wNMW6fjX (22KB)
Full log drive.google.com/file/d/1skkLCOMI5_DKzp … sp=sharing (Warning: 22MB)

Last edited by kaz49 (2025-01-17 02:21:25)

seth · 2025-01-17 10:32:50

Jan 15 11:40:33 kaz49-dynabook systemd-sleep[1111480]: Failed to freeze unit 'user.slice': Connection timed out
Jan 15 11:40:33 kaz49-dynabook systemd-sleep[1111480]: Performing sleep operation 'suspend'...
Jan 15 11:40:33 kaz49-dynabook kernel: PM: suspend entry (s2idle)
Jan 15 11:40:33 kaz49-dynabook kernel: Filesystems sync: 0.014 seconds
Jan 15 11:40:54 kaz49-dynabook kernel: Freezing user space processes
Jan 15 11:40:54 kaz49-dynabook kernel: Freezing user space processes failed after 20.006 seconds (1 tasks refusing to freeze, wq_busy=0):
Jan 15 11:40:54 kaz49-dynabook kernel: task:plasmashell     state:D stack:0     pid:1092  tgid:1092  ppid:794    flags:0x00004006
Jan 15 11:40:54 kaz49-dynabook kernel: Call Trace:
Jan 15 11:40:54 kaz49-dynabook kernel:  <TASK>
Jan 15 11:40:54 kaz49-dynabook kernel:  __schedule+0x3b0/0x12b0
Jan 15 11:40:54 kaz49-dynabook kernel:  ? kmem_cache_alloc_noprof+0x111/0x2f0
Jan 15 11:40:54 kaz49-dynabook kernel:  schedule+0x27/0xf0
Jan 15 11:40:54 kaz49-dynabook kernel:  request_wait_answer+0xd0/0x2b0
Jan 15 11:40:54 kaz49-dynabook kernel:  ? __pfx_autoremove_wake_function+0x10/0x10
Jan 15 11:40:54 kaz49-dynabook kernel:  __fuse_simple_request+0xd7/0x290
Jan 15 11:40:54 kaz49-dynabook kernel:  fuse_send_open+0xb9/0x110
Jan 15 11:40:54 kaz49-dynabook kernel:  fuse_file_open+0x117/0x1a0
Jan 15 11:40:54 kaz49-dynabook kernel:  fuse_open+0x8a/0x320
Jan 15 11:40:54 kaz49-dynabook kernel:  ? __pfx_fuse_open+0x10/0x10
Jan 15 11:40:54 kaz49-dynabook kernel:  do_dentry_open+0x14c/0x4a0
Jan 15 11:40:54 kaz49-dynabook kernel:  vfs_open+0x2e/0xe0

https://wiki.archlinux.org/title/Power_ … _waking_up
But plasmashell hangs in the fuse driver, do you mount some ntfs drive?

The journal for the affected boot is gonna suffice (and not be 22MB)
Eg for the previous (-1) boot:

sudo journalctl -b -1 | curl -F 'file=@-' 0x0.st

kaz49 · 2025-01-18 10:14:45

The Arch Wiki page says:

When such an issue occurs, trying to login (start another session) would fail with
pam_systemd(process:session): Failed to create session: Job 9876 for unit 'session-6.scope' failed with 'frozen'

but I don't have that anywhere in my log. That might be simply because the system freezes before I can ever attempt a login though... do you think I should attempt the fix on that page and see how it goes?

I do have a NTFS partition on my main drive, but I don't have it mounted by default. I have Dolphin mount it for me whenever I need to access it, and it's usually not mounted when the freeze happens.

(base) [~]$ lsblk
NAME        MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
nvme0n1     259:0    0 476.9G  0 disk 
├─nvme0n1p1 259:1    0   260M  0 part 
├─nvme0n1p2 259:2    0    16M  0 part 
├─nvme0n1p3 259:3    0   150G  0 part 
├─nvme0n1p4 259:4    0   990M  0 part 
├─nvme0n1p5 259:5    0  10.6G  0 part 
├─nvme0n1p6 259:6    0    66G  0 part /
├─nvme0n1p7 259:7    0 225.1G  0 part /home
└─nvme0n1p8 259:8    0    24G  0 part [SWAP]
(base) [~]$ sudo fdisk -l
Disk /dev/nvme0n1: 476.94 GiB, 512110190592 bytes, 1000215216 sectors
Disk model: C-E80T512G2-P003D2E19T                  
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: B9881232-F088-4FE4-B372-9DC153791C4B

Device             Start        End   Sectors   Size Type
/dev/nvme0n1p1      2048     534527    532480   260M EFI System
/dev/nvme0n1p2    534528     567295     32768    16M Microsoft reserved
/dev/nvme0n1p3    567296  315140095 314572800   150G Microsoft basic data
/dev/nvme0n1p4 976041984  978069503   2027520   990M Windows recovery environment
/dev/nvme0n1p5 978069504 1000214527  22145024  10.6G Windows recovery environment
/dev/nvme0n1p6 315140096  453552127 138412032    66G Linux filesystem
/dev/nvme0n1p7 503883776  976041983 472158208 225.1G Linux filesystem
/dev/nvme0n1p8 453552128  503883775  50331648    24G Linux swap

Partition table entries are not in disk order.

The link I gave you before is the full journal for the boot that the freeze occurred in. It's 22MB long because the system sleeps normally most of the time, so I'd been using my laptop on that boot for a couple days.
Here's the URL I got from the command in your post (it's the same thing, but this 0x0 website is neat! ) 0x0.st/8Hix.txt

Last edited by kaz49 (2025-01-18 10:22:24)

seth · 2025-01-18 15:05:44

[Me] think [you] should attempt the fix on that page and see how it goes

Then what's the fuse call for?
Sidabar: 3rd link below. Mandatory.
Disable it (it's NOT the BIOS setting!) and reboot windows and linux twice for voodo reasons.

Another popular way to stumble S2idle/S3 is APST, https://wiki.archlinux.org/title/Solid_ … leshooting (loosely fits the fuse involvement)

Salkay · 2025-06-05 06:05:50

@kaz49 did you ever solve this?

I've also had this problem for the last several months, after years of suspending perfectly fine. I looked back in my logs, and it fails 2/50 times, i.e. 4%.

Thanks @seth for all the useful comments as always. I also have nothing obvious in the logs, also can't REISUB nor change TTY. I also don't see the Failed to create session error in my logs. I don't even have a NTFS partition on this system (only a FAT32 ESP and EXT4). I also don't dual boot.

I wonder what other commonalities we share? I also have four other Arch systems that regularly suspend, and none of these have problems. One thing unique about my failing system is that my EXT4 drive is LUKS encrypted. Is yours as well?

I do have a gocrypt image that is mounted all the time, via fuse. Having said that, I have another system with a similar gocrypt/fuse setup that never has this issue with suspend.

Here are some possibly relevant lines from the journal on the failing system though.

Jun 05 13:47:25 work-laptop kernel: Freezing user space processes
Jun 05 13:47:25 work-laptop kernel: Freezing user space processes failed after 20.006 seconds (1 tasks refusing to freeze, wq_busy=0):
Jun 05 13:47:25 work-laptop kernel: task:notmuch         state:D stack:0     pid:905047 tgid:905047 ppid:904818 flags:0x00004006
Jun 05 13:47:25 work-laptop kernel: Call Trace:
Jun 05 13:47:25 work-laptop kernel:  <TASK>
Jun 05 13:47:25 work-laptop kernel:  __schedule+0x3c7/0x12f0
Jun 05 13:47:25 work-laptop kernel:  schedule+0x27/0xf0
Jun 05 13:47:25 work-laptop kernel:  request_wait_answer+0xd0/0x2b0
Jun 05 13:47:25 work-laptop kernel:  ? __pfx_autoremove_wake_function+0x10/0x10
Jun 05 13:47:25 work-laptop kernel:  __fuse_simple_request+0xd5/0x2b0
Jun 05 13:47:25 work-laptop kernel:  fuse_perform_write+0x300/0x820
Jun 05 13:47:25 work-laptop kernel:  fuse_file_write_iter+0x4b5/0x500
Jun 05 13:47:25 work-laptop kernel:  ? vfs_read+0x15c/0x380
Jun 05 13:47:25 work-laptop kernel:  ? vfs_read+0x15c/0x380
Jun 05 13:47:25 work-laptop kernel:  ? security_file_permission+0x48/0x130
Jun 05 13:47:25 work-laptop kernel:  vfs_write+0x290/0x470
Jun 05 13:47:25 work-laptop kernel:  __x64_sys_pwrite64+0x97/0xd0
Jun 05 13:47:25 work-laptop kernel:  do_syscall_64+0x7b/0x190
Jun 05 13:47:25 work-laptop kernel:  ? fuse_file_write_iter+0x4c4/0x500
Jun 05 13:47:25 work-laptop kernel:  ? vfs_write+0x313/0x470
Jun 05 13:47:25 work-laptop kernel:  ? vfs_write+0x313/0x470
Jun 05 13:47:25 work-laptop kernel:  ? __rseq_handle_notify_resume+0x9c/0x4d0
Jun 05 13:47:25 work-laptop kernel:  ? switch_fpu_return+0x4e/0xd0
Jun 05 13:47:25 work-laptop kernel:  ? arch_exit_to_user_mode_prepare.isra.0+0x7c/0x90
Jun 05 13:47:25 work-laptop kernel:  ? syscall_exit_to_user_mode+0x37/0x1c0
Jun 05 13:47:25 work-laptop kernel:  ? do_syscall_64+0x87/0x190
Jun 05 13:47:25 work-laptop kernel:  ? arch_exit_to_user_mode_prepare.isra.0+0x7c/0x90
Jun 05 13:47:25 work-laptop kernel:  ? syscall_exit_to_user_mode+0x37/0x1c0
Jun 05 13:47:25 work-laptop kernel:  ? do_syscall_64+0x87/0x190
Jun 05 13:47:25 work-laptop kernel:  ? clear_bhb_loop+0x40/0x90
Jun 05 13:47:25 work-laptop kernel:  ? clear_bhb_loop+0x40/0x90
Jun 05 13:47:25 work-laptop kernel:  ? clear_bhb_loop+0x40/0x90
Jun 05 13:47:25 work-laptop kernel:  ? clear_bhb_loop+0x40/0x90
Jun 05 13:47:25 work-laptop kernel:  ? clear_bhb_loop+0x40/0x90
Jun 05 13:47:25 work-laptop kernel:  entry_SYSCALL_64_after_hwframe+0x76/0x7e
Jun 05 13:47:25 work-laptop kernel: RIP: 0033:0x7c189d597006
Jun 05 13:47:25 work-laptop kernel: RSP: 002b:00007ffd96809370 EFLAGS: 00000202 ORIG_RAX: 0000000000000012
Jun 05 13:47:25 work-laptop kernel: RAX: ffffffffffffffda RBX: 0000000000002000 RCX: 00007c189d597006
Jun 05 13:47:25 work-laptop kernel: RDX: 0000000000002000 RSI: 000061867384cda8 RDI: 0000000000000007
Jun 05 13:47:25 work-laptop kernel: RBP: 00007ffd96809390 R08: 0000000000000000 R09: 0000000000000000
Jun 05 13:47:25 work-laptop kernel: R10: 0000000005da6000 R11: 0000000000000202 R12: 0000000005da6000
Jun 05 13:47:25 work-laptop kernel: R13: 000061867384cda8 R14: 0000000000000007 R15: 0000000000002ed3
Jun 05 13:47:25 work-laptop kernel:  </TASK>
Jun 05 13:47:25 work-laptop kernel: OOM killer enabled.
Jun 05 13:47:25 work-laptop kernel: Restarting tasks ... done.
Jun 05 13:47:25 work-laptop kernel: random: crng reseeded on system resumption
Jun 05 13:47:25 work-laptop bluetoothd[1217]: Controller resume with wake event 0x0
Jun 05 13:47:25 work-laptop kernel: PM: suspend exit
Jun 05 13:47:25 work-laptop kernel: PM: suspend entry (s2idle)
Jun 05 13:47:25 work-laptop kernel: Filesystems sync: 0.014 seconds
Jun 05 13:47:45 work-laptop kernel: Freezing user space processes
Jun 05 13:47:45 work-laptop kernel: Freezing user space processes failed after 20.011 seconds (1 tasks refusing to freeze, wq_busy=0):

I also tried to see if I had problems related to APST, by grepping for reset controller in the journal, but there was nothing there.

I don't use KVM, but I'll try to disable the "new" user.slice issue and report back. I can't remember exactly when these issues first started, but it's plausible it was around June 2024, when systemd v256 was first released.

E: For the record, that link says "System freezes for 60 seconds and then wakes back up or hangs after waking up". In my case, it doesn't freeze for 60 seconds, it freezes interminably. It also doesn't hang after waking up, but instead never suspends at all. I'll still give the modifications a try though.

Last edited by Salkay (2025-06-05 06:12:03)

seth · 2025-06-05 07:40:44

Can we see a bit more context on the suspend?
Since when are you using notmuch? If you SIGSTOP that before the sleep attempt, do you simply get vfs hangs in another process now?

Salkay · 2025-06-05 07:57:19

Thanks seth. I use notmuch for neomutt, so I presume it's running frequently. However, I don't think it's always in the logs, e.g. here is another time when suspend failed. I've added a bit more of the surrounding log too.

May 26 16:52:15 work-laptop systemd-sleep[670592]: Failed to freeze unit 'user.slice': Connection timed out
May 26 16:52:15 work-laptop systemd-sleep[670592]: Performing sleep operation 'suspend'...
May 26 16:52:15 work-laptop kernel: PM: suspend entry (s2idle)
May 26 16:52:15 work-laptop kernel: Filesystems sync: 0.014 seconds
May 26 16:52:35 work-laptop kernel: Freezing user space processes
May 26 16:52:35 work-laptop kernel: Freezing user space processes failed after 20.007 seconds (1 tasks refusing to freeze, wq_busy=0):
May 26 16:52:35 work-laptop kernel: task:DOMCacheThread  state:D stack:0     pid:670596 tgid:4688  ppid:1325   flags:0x00004006
May 26 16:52:35 work-laptop kernel: Call Trace:
May 26 16:52:35 work-laptop kernel:  <TASK>
May 26 16:52:35 work-laptop kernel:  __schedule+0x3c7/0x12f0
May 26 16:52:35 work-laptop kernel:  schedule+0x27/0xf0
May 26 16:52:35 work-laptop kernel:  request_wait_answer+0xd0/0x2b0
May 26 16:52:35 work-laptop kernel:  ? __pfx_autoremove_wake_function+0x10/0x10
May 26 16:52:35 work-laptop kernel:  __fuse_simple_request+0xd5/0x2b0
May 26 16:52:35 work-laptop kernel:  fuse_fsync_common+0x99/0xc0
May 26 16:52:35 work-laptop kernel:  fuse_fsync+0xe7/0x110
May 26 16:52:35 work-laptop kernel:  do_fsync+0x3c/0x80
May 26 16:52:35 work-laptop kernel:  __x64_sys_fsync+0x13/0x20
May 26 16:52:35 work-laptop kernel:  do_syscall_64+0x7b/0x190
May 26 16:52:35 work-laptop kernel:  ? vfs_write+0x313/0x470
May 26 16:52:35 work-laptop kernel:  ? vfs_write+0x313/0x470
May 26 16:52:35 work-laptop kernel:  ? __rseq_handle_notify_resume+0x9c/0x4d0
May 26 16:52:35 work-laptop kernel:  ? arch_exit_to_user_mode_prepare.isra.0+0x7c/0x90
May 26 16:52:35 work-laptop kernel:  ? syscall_exit_to_user_mode+0x37/0x1c0
May 26 16:52:35 work-laptop kernel:  ? do_syscall_64+0x87/0x190
May 26 16:52:35 work-laptop kernel:  ? vfs_write+0x3b4/0x470
May 26 16:52:35 work-laptop kernel:  ? ksys_write+0xda/0xf0
May 26 16:52:35 work-laptop kernel:  ? syscall_exit_to_user_mode+0x37/0x1c0
May 26 16:52:35 work-laptop kernel:  ? do_syscall_64+0x87/0x190
May 26 16:52:35 work-laptop kernel:  ? syscall_exit_to_user_mode+0x37/0x1c0
May 26 16:52:35 work-laptop kernel:  ? do_syscall_64+0x87/0x190
May 26 16:52:35 work-laptop kernel:  ? handle_mm_fault+0x1b6/0x2c0
May 26 16:52:35 work-laptop kernel:  ? do_user_addr_fault+0x36c/0x640
May 26 16:52:35 work-laptop kernel:  ? clear_bhb_loop+0x40/0x90
May 26 16:52:35 work-laptop kernel:  ? clear_bhb_loop+0x40/0x90
May 26 16:52:35 work-laptop kernel:  ? clear_bhb_loop+0x40/0x90
May 26 16:52:35 work-laptop kernel:  ? clear_bhb_loop+0x40/0x90
May 26 16:52:35 work-laptop kernel:  ? clear_bhb_loop+0x40/0x90
May 26 16:52:35 work-laptop kernel:  entry_SYSCALL_64_after_hwframe+0x76/0x7e
May 26 16:52:35 work-laptop kernel: RIP: 0033:0x7c14796ade22
May 26 16:52:35 work-laptop kernel: RSP: 002b:00007c144f951c78 EFLAGS: 00000246 ORIG_RAX: 000000000000004a
May 26 16:52:35 work-laptop kernel: RAX: ffffffffffffffda RBX: 00007c1453585e50 RCX: 00007c14796ade22
May 26 16:52:35 work-laptop kernel: RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000056
May 26 16:52:35 work-laptop kernel: RBP: 00007c144f951cb0 R08: 0000000000000000 R09: 0000000000000000
May 26 16:52:35 work-laptop kernel: R10: 0000000000000000 R11: 0000000000000246 R12: 00007c1453585da0
May 26 16:52:35 work-laptop kernel: R13: 0000000000000001 R14: 00007c144f951ddc R15: 0000000000000000
May 26 16:52:35 work-laptop kernel:  </TASK>
May 26 16:52:35 work-laptop kernel: OOM killer enabled.
May 26 16:52:35 work-laptop kernel: Restarting tasks ... done.
May 26 16:52:35 work-laptop kernel: random: crng reseeded on system resumption
May 26 16:52:35 work-laptop rtkit-daemon[1792]: The canary thread is apparently starving. Taking action.
May 26 16:52:35 work-laptop rtkit-daemon[1792]: Demoting known real-time threads.
May 26 16:52:35 work-laptop rtkit-daemon[1792]: Demoted 0 threads.
May 26 16:52:35 work-laptop bluetoothd[1168]: Controller resume with wake event 0x0
May 26 16:52:35 work-laptop kernel: PM: suspend exit
May 26 16:52:35 work-laptop kernel: PM: suspend entry (s2idle)
May 26 16:52:35 work-laptop kernel: Filesystems sync: 0.013 seconds
May 26 16:52:55 work-laptop kernel: Freezing user space processes
May 26 16:52:55 work-laptop kernel: Freezing user space processes failed after 20.002 seconds (1 tasks refusing to freeze, wq_busy=0):
May 26 16:52:55 work-laptop kernel: task:DOMCacheThread  state:D stack:0     pid:670596 tgid:4688  ppid:1325   flags:0x00004006
May 26 16:52:55 work-laptop kernel: Call Trace:
May 26 16:52:55 work-laptop kernel:  <TASK>
May 26 16:52:55 work-laptop kernel:  __schedule+0x3c7/0x12f0
May 26 16:52:55 work-laptop kernel:  schedule+0x27/0xf0
May 26 16:52:55 work-laptop kernel:  request_wait_answer+0xd0/0x2b0
May 26 16:52:55 work-laptop kernel:  ? __pfx_autoremove_wake_function+0x10/0x10
May 26 16:52:55 work-laptop kernel:  __fuse_simple_request+0xd5/0x2b0
May 26 16:52:55 work-laptop kernel:  fuse_fsync_common+0x99/0xc0
May 26 16:52:55 work-laptop kernel:  fuse_fsync+0xe7/0x110
May 26 16:52:55 work-laptop kernel:  do_fsync+0x3c/0x80
May 26 16:52:55 work-laptop kernel:  __x64_sys_fsync+0x13/0x20
May 26 16:52:55 work-laptop kernel:  do_syscall_64+0x7b/0x190
May 26 16:52:55 work-laptop kernel:  ? vfs_write+0x313/0x470
May 26 16:52:55 work-laptop kernel:  ? vfs_write+0x313/0x470
May 26 16:52:55 work-laptop kernel:  ? __rseq_handle_notify_resume+0x9c/0x4d0
May 26 16:52:55 work-laptop kernel:  ? arch_exit_to_user_mode_prepare.isra.0+0x7c/0x90
May 26 16:52:55 work-laptop kernel:  ? syscall_exit_to_user_mode+0x37/0x1c0
May 26 16:52:55 work-laptop kernel:  ? do_syscall_64+0x87/0x190
May 26 16:52:55 work-laptop kernel:  ? vfs_write+0x3b4/0x470
May 26 16:52:55 work-laptop kernel:  ? ksys_write+0xda/0xf0
May 26 16:52:55 work-laptop kernel:  ? syscall_exit_to_user_mode+0x37/0x1c0
May 26 16:52:55 work-laptop kernel:  ? do_syscall_64+0x87/0x190
May 26 16:52:55 work-laptop kernel:  ? syscall_exit_to_user_mode+0x37/0x1c0
May 26 16:52:55 work-laptop kernel:  ? do_syscall_64+0x87/0x190
May 26 16:52:55 work-laptop kernel:  ? handle_mm_fault+0x1b6/0x2c0
May 26 16:52:55 work-laptop kernel:  ? do_user_addr_fault+0x36c/0x640
May 26 16:52:55 work-laptop kernel:  ? clear_bhb_loop+0x40/0x90
May 26 16:52:55 work-laptop kernel:  ? clear_bhb_loop+0x40/0x90
May 26 16:52:55 work-laptop kernel:  ? clear_bhb_loop+0x40/0x90
May 26 16:52:55 work-laptop kernel:  ? clear_bhb_loop+0x40/0x90
May 26 16:52:55 work-laptop kernel:  ? clear_bhb_loop+0x40/0x90
May 26 16:52:55 work-laptop kernel:  entry_SYSCALL_64_after_hwframe+0x76/0x7e
May 26 16:52:55 work-laptop kernel: RIP: 0033:0x7c14796ade22
May 26 16:52:55 work-laptop kernel: RSP: 002b:00007c144f951c78 EFLAGS: 00000246 ORIG_RAX: 000000000000004a
May 26 16:52:55 work-laptop kernel: RAX: ffffffffffffffda RBX: 00007c1453585e50 RCX: 00007c14796ade22
May 26 16:52:55 work-laptop kernel: RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000056
May 26 16:52:55 work-laptop kernel: RBP: 00007c144f951cb0 R08: 0000000000000000 R09: 0000000000000000
May 26 16:52:55 work-laptop kernel: R10: 0000000000000000 R11: 0000000000000246 R12: 00007c1453585da0
May 26 16:52:55 work-laptop kernel: R13: 0000000000000001 R14: 00007c144f951ddc R15: 0000000000000000
May 26 16:52:55 work-laptop kernel:  </TASK>
May 26 16:52:55 work-laptop kernel: OOM killer enabled.
May 26 16:52:55 work-laptop kernel: Restarting tasks ... done.
May 26 16:52:55 work-laptop kernel: random: crng reseeded on system resumption
May 26 16:52:55 work-laptop rtkit-daemon[1792]: The canary thread is apparently starving. Taking action.
May 26 16:52:55 work-laptop rtkit-daemon[1792]: Demoting known real-time threads.
May 26 16:52:55 work-laptop rtkit-daemon[1792]: Demoted 0 threads.
May 26 16:52:55 work-laptop systemd-sleep[670592]: Failed to put system to sleep. System resumed again: Device or resource busy
May 26 16:52:55 work-laptop bluetoothd[1168]: Controller resume with wake event 0x0
May 26 16:52:55 work-laptop kernel: PM: suspend exit
May 26 16:52:56 work-laptop systemd-sleep[670592]: Successfully thawed unit 'user.slice'.
May 26 16:52:56 work-laptop systemd[1]: systemd-suspend.service: Main process exited, code=exited, status=1/FAILURE
May 26 16:52:56 work-laptop systemd[1]: systemd-suspend.service: Failed with result 'exit-code'.
May 26 16:52:56 work-laptop systemd[1]: Failed to start System Suspend.
May 26 16:52:56 work-laptop systemd[1]: Dependency failed for Suspend.
May 26 16:52:56 work-laptop systemd[1]: suspend.target: Job suspend.target/start failed with result 'dependency'.
May 26 16:52:56 work-laptop systemd[1]: systemd-suspend.service: Consumed 3.958s CPU time, 7.4M memory peak.
May 26 16:52:56 work-laptop systemd-logind[1176]: Operation 'suspend' finished.
May 26 16:52:56 work-laptop NetworkManager[1167]: <info>  [1748242376.2278] manager: sleep: wake requested (sleeping: yes  enabled: yes)
May 26 16:52:56 work-laptop NetworkManager[1167]: <info>  [1748242376.2279] device (wlan0): state change: unmanaged -> unavailable (reason 'managed', managed-type: 'external')
May 26 16:52:56 work-laptop systemd[1]: session-2.scope: Unit now frozen.
May 26 16:52:56 work-laptop systemd[1]: Stopped target Sleep.
May 26 16:52:56 work-laptop NetworkManager[1167]: <info>  [1748242376.2295] device (p2p-dev-wlan0): state change: unmanaged -> unavailable (reason 'managed', managed-type: 'external')
May 26 16:52:56 work-laptop NetworkManager[1167]: <info>  [1748242376.2298] manager: NetworkManager state is now DISCONNECTED
May 26 16:52:56 work-laptop systemd[1]: Starting Call user's suspend target after system suspend...
May 26 16:52:56 work-laptop NetworkManager[1167]: <info>  [1748242376.2903] device (wlan0): supplicant interface state: internal-starting -> disconnected
May 26 16:52:56 work-laptop NetworkManager[1167]: <info>  [1748242376.2904] device (p2p-dev-wlan0): state change: unavailable -> unmanaged (reason 'unmanaged-link-not-init', managed-type: 'removed')
May 26 16:52:56 work-laptop NetworkManager[1167]: <info>  [1748242376.2913] Wi-Fi P2P device controlled by interface wlan0 created
May 26 16:52:56 work-laptop NetworkManager[1167]: <info>  [1748242376.2917] manager: (p2p-dev-wlan0): new 802.11 Wi-Fi P2P device (/org/freedesktop/NetworkManager/Devices/81)
May 26 16:52:56 work-laptop NetworkManager[1167]: <info>  [1748242376.2922] device (p2p-dev-wlan0): state change: unmanaged -> unavailable (reason 'managed', managed-type: 'external')
May 26 16:52:56 work-laptop NetworkManager[1167]: <info>  [1748242376.2931] device (wlan0): state change: unavailable -> disconnected (reason 'supplicant-available', managed-type: 'full')
May 26 16:52:56 work-laptop systemd[1]: Started [systemd-run] systemd-stdio-bridge "-punix:path=\${XDG_RUNTIME_DIR}/bus".
May 26 16:52:56 work-laptop NetworkManager[1167]: <info>  [1748242376.2943] device (p2p-dev-wlan0): state change: unavailable -> disconnected (reason 'none', managed-type: 'full')
May 26 16:52:56 work-laptop (o-bridge)[670820]: pam_unix(login:session): session opened for user salkay(uid=1000) by salkay(uid=0)
May 26 16:52:56 work-laptop systemd[1]: Started Session 1962 of User salkay.
May 26 16:52:59 work-laptop NetworkManager[1167]: <info>  [1748242379.4232] policy: auto-activating connection 'foobar' (429cbf23-404d-45aa-93c3-f9af94e2dcb7)
May 26 16:52:59 work-laptop NetworkManager[1167]: <info>  [1748242379.4237] device (wlan0): Activation: starting connection 'foobar' (429cbf23-404d-45aa-93c3-f9af94e2dcb7)
May 26 16:52:59 work-laptop NetworkManager[1167]: <info>  [1748242379.4238] device (wlan0): state change: disconnected -> prepare (reason 'none', managed-type: 'full')
May 26 16:52:59 work-laptop NetworkManager[1167]: <info>  [1748242379.4239] manager: NetworkManager state is now CONNECTING
May 26 16:52:59 work-laptop NetworkManager[1167]: <info>  [1748242379.4241] device (wlan0): state change: prepare -> config (reason 'none', managed-type: 'full')
May 26 16:52:59 work-laptop NetworkManager[1167]: <info>  [1748242379.4243] device (wlan0): Activation: (wifi) access point 'foobar' has security, but secrets are required.
May 26 16:52:59 work-laptop NetworkManager[1167]: <info>  [1748242379.4243] device (wlan0): state change: config -> need-auth (reason 'none', managed-type: 'full')
May 26 16:54:26 work-laptop systemctl[670816]: Failed to start suspend.target: Transport endpoint is not connected
May 26 16:54:26 work-laptop systemctl[670816]: See user logs and 'systemctl --user status suspend.target' for details.
May 26 16:54:26 work-laptop systemd[1]: suspend@salkay.service: Main process exited, code=exited, status=1/FAILURE
May 26 16:54:26 work-laptop systemd[1]: suspend@salkay.service: Failed with result 'exit-code'.
May 26 16:54:26 work-laptop systemd[1]: Failed to start Call user's suspend target after system suspend.

Notmuch wasn't running right now, so I couldn't SIGSTOP to test. But that's an interesting point... if it's running 4% of the time, then it could be some intermittent process that is causing the hang. Also, notmuch is working on my local mail, which is on the fuse-mounted device, so it could be related.

seth · 2025-06-05 13:32:54

'key - what /is/ the "fuse mounted device" and what fuse specifically?
Also we want to look at the journal *at least* from when you initiate the sleep - the last bit start w/ a timeout failure to freeze the user session stuff already, https://bbs.archlinux.org/viewtopic.php?id=296954

Salkay · 2025-06-10 02:46:33

Thanks again @seth. I've been waiting for suspend to fail again before posting longer logs, but it hasn't quite failed yet. I'll post more when it fails (unless my modifications to user.slice have fixed it).

On my system the fuse device is gocrypt image that is decrypted soon after I log in, and stays decrypted all the time.

seth · 2025-06-10 07:04:52

plasma or some hook probably wants to close the vault before going to bed, but can't because some file there is kept open?
"tail -f /path/to/a/file/in/the/crypt", then trigger a suspend - does that cause the failure?
Does it if you sudo the tail?

Salkay · 2025-06-10 07:10:57

seth wrote:

plasma or some hook probably wants to close the vault before going to bed, but can't because some file there is kept open?
"tail -f /path/to/a/file/in/the/crypt", then trigger a suspend - does that cause the failure?

I tried this, but it's fine. (But again perhaps my modifications to user.slice have fixed it.) Also, as above I have another system with a similar gocrypt/fuse setup that never has this issue with suspend.

seth wrote:

Does it if you sudo the tail?

Oddly enough I can't access the file with sudo; I get Permission denied. Presumably it's some way that gocrypt functions.

Arch Linux

#1 2025-01-15 03:44:55

System sometimes irreversibly freezes when I try to suspend

#2 2025-01-15 14:45:16

Re: System sometimes irreversibly freezes when I try to suspend

#3 2025-01-17 02:20:51

Re: System sometimes irreversibly freezes when I try to suspend

#4 2025-01-17 10:32:50

Re: System sometimes irreversibly freezes when I try to suspend

#5 2025-01-18 10:14:45

Re: System sometimes irreversibly freezes when I try to suspend

#6 2025-01-18 15:05:44

Re: System sometimes irreversibly freezes when I try to suspend

#7 2025-06-05 06:05:50

Re: System sometimes irreversibly freezes when I try to suspend

#8 2025-06-05 07:40:44

Re: System sometimes irreversibly freezes when I try to suspend

#9 2025-06-05 07:57:19

Re: System sometimes irreversibly freezes when I try to suspend

#10 2025-06-05 13:32:54

Re: System sometimes irreversibly freezes when I try to suspend

#11 2025-06-10 02:46:33

Re: System sometimes irreversibly freezes when I try to suspend

#12 2025-06-10 07:04:52

Re: System sometimes irreversibly freezes when I try to suspend

#13 2025-06-10 07:10:57

Re: System sometimes irreversibly freezes when I try to suspend

Board footer