Bug#713852: dmsetup remove <nonexistent_device> waits forever
Milan Broz
gmazyland at gmail.com
Sun Jun 23 09:45:58 UTC 2013
Package: dmsetup
Version: 2:1.02.77-3
Severity: important
If you run "dmsetup remove" for non existent device, tool must
return immediately.
Now it waits for udev:
dmsetup remove loop0
...
open("/run/udev/queue.bin", O_RDONLY|O_CLOEXEC) = 4
fstat(4, {st_mode=S_IFREG|0644, st_size=8, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fed62b0a000
read(4, "\333\5\0\0\0\0\0\0", 4096) = 8
close(4) = 0
munmap(0x7fed62b0a000, 4096) = 0
open("/dev/urandom", O_RDONLY) = 4
read(4, "n\301", 2) = 2
close(4) = 0
socket(PF_NETLINK, SOCK_RAW|SOCK_CLOEXEC|SOCK_NONBLOCK, 15) = 4
setsockopt(4, SOL_SOCKET, SO_ATTACH_FILTER, "\n\0\0\0\0\0\0\0\220\277)I\377\177\0\0", 16) = 0
bind(4, {sa_family=AF_NETLINK, pid=0, groups=00000002}, 12) = 0
getsockname(4, {sa_family=AF_NETLINK, pid=10887, groups=00000002}, [12]) = 0
setsockopt(4, SOL_SOCKET, SO_PASSCRED, [1], 4) = 0
ioctl(3, DM_DEV_REMOVE, 0x6185f0) = -1 ENXIO (No such device or address)
open("/usr/share/locale/en_US.UTF-8/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/locale/en_US.utf8/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/locale/en_US/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/locale/en.UTF-8/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/locale/en.utf8/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/locale/en/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
write(2, "device-mapper: remove ioctl on l"..., 70device-mapper: remove ioctl on loop0 failed: No such device or address) = 70
write(2, "\n", 1
) = 1
poll([{fd=4, events=POLLIN}], 1, 4294967295^C <unfinished ...>
^^^ it cannot receive event for device which doesn't exist!
After short search I found this upstream response to Debian approach
https://www.redhat.com/archives/lvm-devel/2013-June/msg00353.html
IMHO it is very good idea to use udev monitor but it must be done properly.
Seems like Debian uses untested patches and diverts from upstream. Why?
All other packages which use device-mapper are affected too
(only additional checks for device existence prevents to happen this
loop for cryptsetup close/remove command for example).
-- System Information:
Debian Release: jessie/sid
APT prefers unstable
APT policy: (990, 'unstable'), (500, 'testing'), (500, 'oldstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.9.4 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages dmsetup depends on:
ii libc6 2.17-5
ii libdevmapper1.02.1 2:1.02.77-3
ii libudev0 175-7.2
ii util-linux 2.20.1-5.4
dmsetup recommends no packages.
dmsetup suggests no packages.
-- no debconf information
More information about the pkg-lvm-maintainers
mailing list