The important part with that socket is that it is used in udev rules
to detect path add/remove/changes, and update multipath accordingly.
If 'multipath -u /dev/sdX' hangs waiting for the socket, the paths
fail that udev handling, timeout the udev workers, and don't get
the /required/ udev properties to be added to right multipath maps.
There is another bug report here, duplicated to this one internally,
which shows all paths in multipath -l listed with #:#:#:# SCSI addresses
because of that, thus the paths become unused..
All because of that socket failed somehow, causing the hang.
BUT
For some reason, it's working fine despite the socket unit failure
(wondering if the multipathd service dealt with it.)
# strace -e connect multipath -u /dev/sda
connect(4, {sa_family=AF_LOCAL,
sun_path=@"/org/kernel/linux/storage/multipathd"}, 39) = 0
connect(4, {sa_family=AF_LOCAL, sun_path="/dev/log"}, 110) = 0
+++ exited with 1 +++
# udevadm test --action=add /block/sda
<...>
ID_SERIAL=0QEMU_QEMU_HARDDISK_drive-scsi0-0-0-0
<...>
# echo $?
0
So I guess this patch indeed helps.
It would be good (or possibly important, if the socket accidentally working
is actually an intermittent thing) to have the socket unit activation fixed.
For that I think we'll need the timing-based approach to wait for the socket
to be closed/released.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1670811
Title:
Multipath services fails to start on Ubuntu 17.04 on boot and kdump
(initramfs)
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/multipath-tools/+bug/1670811/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
