Systemd can still block us from (re-?)suspending
I was playing around with re-suspending the system (#10) in branch resuspend
.
The prototype code looks like:
# suspend
/bin/cryptroot-suspend \"$CRYPTNAME\"
# continue here after suspend
# retry eternally to re-open cryptroot
while ! cryptsetup luksResume \"$CRYPTNAME\"; do
echo 0 > /sys/power/sync_on_suspend
echo \"mem\" > /sys/power/state
echo 1 > /sys/power/sync_on_suspend
done
When trying to re-suspend systemd will sometimes block me:
kernel: [ 109.361916] Freezing of tasks failed after 19.992 seconds (1 tasks refusing to freeze, wq_busy=0):
kernel: [ 109.362013] systemd D 0 1 0 0x00004004
kernel: [ 109.362019] Call Trace:
kernel: [ 109.362039] ? __schedule+0x2bb/0x660
kernel: [ 109.362045] ? bit_wait_timeout+0x90/0x90
kernel: [ 109.362050] schedule+0x2f/0xa0
kernel: [ 109.362055] io_schedule+0x12/0x40
kernel: [ 109.362060] bit_wait_io+0xd/0x50
kernel: [ 109.362065] __wait_on_bit+0x73/0x90
kernel: [ 109.362071] out_of_line_wait_on_bit+0x91/0xb0
kernel: [ 109.362079] ? init_wait_var_entry+0x40/0x40
kernel: [ 109.362087] bh_submit_read+0x7f/0x83
kernel: [ 109.362132] __read_extent_tree_block+0x1b2/0x230 [ext4]
kernel: [ 109.362139] ? _cond_resched+0x15/0x30
kernel: [ 109.362167] ? ext4_find_extent+0x13e/0x310 [ext4]
kernel: [ 109.362194] ? ext4_find_extent+0x278/0x310 [ext4]
kernel: [ 109.362222] ext4_find_extent+0x13e/0x310 [ext4]
kernel: [ 109.362253] ext4_ext_map_blocks+0x6a/0xd60 [ext4]
kernel: [ 109.362259] ? mem_cgroup_commit_charge+0x80/0x4d0
kernel: [ 109.362263] ? mem_cgroup_try_charge+0x86/0x190
kernel: [ 109.362268] ? cpumask_next+0x16/0x20
kernel: [ 109.362303] ext4_map_blocks+0x2e4/0x5f0 [ext4]
kernel: [ 109.362346] ext4_mpage_readpages+0x510/0x860 [ext4]
kernel: [ 109.362356] read_pages+0x6b/0x190
kernel: [ 109.362365] __do_page_cache_readahead+0x1c1/0x1e0
kernel: [ 109.362372] filemap_fault+0x6d3/0x970
kernel: [ 109.362379] ? __wake_up_common_lock+0x89/0xc0
kernel: [ 109.362385] ? xas_load+0x8/0x80
kernel: [ 109.362389] ? xas_find+0x150/0x190
kernel: [ 109.362393] ? filemap_map_pages+0x1b9/0x390
kernel: [ 109.362430] ext4_filemap_fault+0x2c/0x40 [ext4]
kernel: [ 109.362440] __do_fault+0x36/0x120
kernel: [ 109.362446] __handle_mm_fault+0xe98/0x1280
kernel: [ 109.362454] handle_mm_fault+0xbe/0x1d0
kernel: [ 109.362459] __do_page_fault+0x249/0x4f0
kernel: [ 109.362465] ? page_fault+0x8/0x30
kernel: [ 109.362469] page_fault+0x1e/0x30
kernel: [ 109.362474] RIP: 0033:0x7f9f65f03e23
kernel: [ 109.362486] Code: Bad RIP value.
kernel: [ 109.362489] RSP: 002b:00007fffa6c7f428 EFLAGS: 00010293
kernel: [ 109.362492] RAX: 0000000000000003 RBX: 000055b8c08a2060 RCX: 000055b8c08cf980
kernel: [ 109.362494] RDX: 00007f9f66022f90 RSI: 0000000000000003 RDI: 000055b8c078a4e0
kernel: [ 109.362496] RBP: 0000000000000001 R08: 000055b8c078d398 R09: 000055b8c08a2098
kernel: [ 109.362499] R10: 0000000000000010 R11: 0000000000000000 R12: 0000000002c662a2
kernel: [ 109.362501] R13: 000055b8c078a550 R14: 00007fffa6c7f47c R15: 0000000000000001
This is happening, when I
- boot
- login to Gnome
- suspend directly
- enter password 3 times wrong
There seem to be times, when systemd still wants to access the root home.