Comment # 9 on bug 1175850 from
Created attachment 843606 [details]
Hung systemd-cryptsetup stack strace

(In reply to Fabian Vogt from comment #7)
> 
> So it seems like systemd-journald.service doesn't reach stopped for some
> reason.


nope. I can reproduce it using TW in QEMU installed with transnational desktop
and separate /var partition. For some reasons it happens only with Plymouth
disabled. I checked that systemd-journald correctly relinquishes /var and /var
is unmounted. But systemd-cryptsetup hangs.

I attach full log from systemd debug shell; most interesting part is stack
trace.

(gdb) bt
#0  __semtimedop (semid=4, sops=sops@entry=0x7ffe1a874a62, nsops=nsops@entry=1,
timeout=timeout@entry=0x0) at ../sysdeps/unix/sysv/linux/semtimedop.c:33
#1  0x00007fd0ebf2da4b in semop (semid=<optimized out>,
sops=sops@entry=0x7ffe1a874a62, nsops=nsops@entry=1) at
../sysdeps/unix/sysv/linux/semop.c:29
#2  0x00007fd0ebac4bbd in _udev_wait (cookie=223200190,
nowait=nowait@entry=0x7ffe1a874a94) at libdm-common.c:2768
#3  0x00007fd0ebac4cf8 in dm_udev_wait (cookie=<optimized out>) at
libdm-common.c:2787
#4  0x00007fd0ec04afe7 in _dm_remove.constprop.0
(name=name@entry=0x7ffe1a875efe "cr_var", deferred=deferred@entry=0,
udev_wait=1) at lib/libdevmapper.c:1022
#5  0x00007fd0ec0217da in dm_remove_device (cd=0x557d701ae950,
name=0x7ffe1a875efe "cr_var", flags=<optimized out>) at lib/libdevmapper.c:1155
#6  0x00007fd0ec009dce in crypt_deactivate_by_name (cd=0x557d701ae950,
name=0x7ffe1a875efe "cr_var", flags=0) at lib/setup.c:4510
#7  0x0000557d6fa9f286 in run (argc=3, argv=0x7ffe1a875258) at
../src/cryptsetup/cryptsetup.c:1037
#8  0x0000557d6fa9d656 in main (argc=<optimized out>, argv=<optimized out>) at
../src/cryptsetup/cryptsetup.c:1047

This appears to be fundamental problem with any device-mapper command that
survives udevd. Quick glance at cryptsetup does not offer any possibility to
disable udev integration for specific invocation - it is hard-coded. But that
is just one of possible consumers of device-mapper, so is the wrong place to
fix it in any way.

I do not claim to understand what device-mapper does or waits for. Cc lvm2
maintainers ...


You are receiving this mail because: