Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=794721
The udev_queue_get_udev_is_active() API call of libudev is used by
things like device-mapper to determine if it should wait for udev to settle
after doing various operations. The catch is that this API call only checks
whether or not the file /run/udev/control exists.
Up until udev 221-1, this file was removed by udev on shutdown. Starting
with 221-1 the file is left behind causing libudev to falsely report to
device-mapper that udev is running which causes device-mapper to hang
indefinitely for a notification that will never arrive.
This causes an indefinite hang during system halt/reboot because udev is
killed off right away by sendsigs long before cryptsetup/dmsetup runs to
close the device-mapper filesystems. The only way to recover is to
physically power cycle the system.
This regression was introduced in commit:
693d371 udevd: move main-loop to sd-event
and affects udev when being run under non-systemd systems.
Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=794721
The udev_queue_get_udev_is_active() API call of libudev is used by
things like device-mapper to determine if it should wait for udev to settle
after doing various operations. The catch is that this API call only checks
whether or not the file /run/udev/control exists.
Up until udev 221-1, this file was removed by udev on shutdown. Starting
with 221-1 the file is left behind causing libudev to falsely report to
device-mapper that udev is running which causes device-mapper to hang
indefinitely for a notification that will never arrive.
This causes an indefinite hang during system halt/reboot because udev is
killed off right away by sendsigs long before cryptsetup/dmsetup runs to
close the device-mapper filesystems. The only way to recover is to
physically power cycle the system.
This regression was introduced in commit:
693d371 udevd: move main-loop to sd-event
and affects udev when being run under non-systemd systems.