libudev uses existence of file /run/udev/control to check if udev is running. Some software, like cryptsetup, checks if udev is running, and if it does run, tries to interact with udev. In case udev isn't actually running while it's indicated otherwise by existence of that file, cryptsetup hangs forever. I think udev must clean up that file when udev service is stopped. Udev availability check code in question: https://github.com/systemd/systemd/blob/bee33d05276326f32a9e677eee6526d3935d0106/src/libudev/libudev-queue.c#L132-L134 Reproducible: Always Steps to Reproduce: 1. Use openrc 2. ensure that sys-fs/cryptsetup and sys-fs/lvm2 are built with "udev" USE-flag enabled 3. prepare encrypted partition like at https://wiki.gentoo.org/wiki/Dm-crypt 4. stop udev service: /etc/init.d/udev stop --nodeps 5. try opening or closing luks device: cryptsetup luksClose $name Actual Results: cryptsetup hangs forever, only "kill -SIGKILL" can stop it. Expected Results: cryptsetup must work without hanging. It works as expected with sys-fs/eudev-3.2.10-r1. Backtrace of hang when running "cryptsetup luksClose testcrypt": (gdb) bt #0 0x00007ffff7cc858a in semtimedop () from /lib64/libc.so.6 #1 0x00007ffff7b75823 in _udev_wait (cookie=223197198, nowait=0x7fffffffd7f0) at libdm-common.c:2769 #2 0x00007ffff7b75908 in dm_udev_wait (cookie=223197198) at libdm-common.c:2788 #3 0x00007ffff7e19e28 in _dm_remove (name=0x7fffffffe175 "testcrypt", udev_wait=1, deferred=0) at lib/libdevmapper.c:1053 #4 0x00007ffff7e1a2cf in dm_remove_device (cd=0x5555555820d0, name=0x7fffffffe175 "testcrypt", flags=0) at lib/libdevmapper.c:1186 #5 0x00007ffff7e3d45c in LUKS2_deactivate (cd=0x5555555820d0, name=0x7fffffffe175 "testcrypt", hdr=0x555555582150, dmd=0x7fffffffdc20, flags=0) at lib/luks2/luks2_json_metadata.c:2274 #6 0x00007ffff7e074b7 in crypt_deactivate_by_name (cd=0x5555555820d0, name=0x7fffffffe175 "testcrypt", flags=0) at lib/setup.c:4521 #7 0x00005555555623d9 in action_close () at src/cryptsetup.c:709 #8 0x000055555556c132 in run_action (action=0x555555578628 <action_types+40>) at src/cryptsetup.c:3569 #9 0x000055555556dfbb in main (argc=3, argv=0x7fffffffdec8) at src/cryptsetup.c:4132
Created attachment 736654 [details] emerge-info.txt $ emerge --info sys-fs/udev sys-fs/cryptsetup sys-fs/lvm2
When running systemd, the socket is managed by PID 1 as specified in systemd-udevd-control.socket. When the socket unit is stopped, /run/udev/control gets unlinked. When running OpenRC, systemd-udevd creates /run/udev/control itself. It does not unlink the socket on shutdown.
We should probably update udev-init-scripts to unlink the socket after udevd is stopped.
(In reply to Mike Gilbert from comment #2) > When running systemd, the socket is managed by PID 1 as specified in > systemd-udevd-control.socket. When the socket unit is stopped, > /run/udev/control gets unlinked. > > When running OpenRC, systemd-udevd creates /run/udev/control itself. It does > not unlink the socket on shutdown. When I tested it on xubuntu 20.04 with systemd (version 245.4-4ubuntu3.11), it didn't unlink /run/udev/control for me either when I masked udev sockets and stopped udev service and ensured that no udev processes remain. Didn't test it on Gentoo with systemd. It doesn't look like systemd removes /run/udev/control either, or I did something wrong when testing it.
Created attachment 736657 [details, diff] udev: unlink control socket after stopping udevd
(In reply to i.Dark_Templar from comment #4) > # ls -l /run/udev/control > srw------- 1 root root 0 Aug 29 12:15 /run/udev/control > # systemctl stop systemd-udevd-control.socket > # ls -l /run/udev/control > ls: cannot access '/run/udev/control': No such file or directory
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/proj/udev-gentoo-scripts.git/commit/?id=93777e58b134935a485214e4f13dce2f2cebb800 commit 93777e58b134935a485214e4f13dce2f2cebb800 Author: Mike Gilbert <floppym@gentoo.org> AuthorDate: 2021-08-29 16:41:40 +0000 Commit: William Hubbs <williamh@gentoo.org> CommitDate: 2021-08-29 18:38:33 +0000 udev: unlink control socket after stopping udevd Closes: https://bugs.gentoo.org/810928 Signed-off-by: Mike Gilbert <floppym@gentoo.org> Signed-off-by: William Hubbs <williamh@gentoo.org> init.d/udev | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
Hmm... looking more closely, the code to unlink the control socket is still present in udevd. I wonder why it isn't working...
Patch sent upstream.
Upstream basically rejected the patch. The init script fix will suffice.
