multipath: check on multipathd without starting it
authorBenjamin Marzinski <bmarzins@redhat.com>
Thu, 18 Apr 2019 17:49:46 +0000 (12:49 -0500)
committerChristophe Varoqui <christophe.varoqui@opensvc.com>
Fri, 19 Apr 2019 13:36:41 +0000 (15:36 +0200)
commit8cdf66614d825639f43f5a6bb20e45b452d29345
treeac067a23fc674cbf69def2087d122fbef735461b
parente23b5d7cf67a9c543e118f2f6b902594a02a804a
multipath: check on multipathd without starting it

When "multipath -u" is run, it checks if multipathd is running.
Currently it does this by trying to connect to the mutipathd socket.
This can cause problems during boot.  The multipathd.socket systemd unit
file will cause "multipath -u" to wait until multipathd has been started
before continuing.  If there is a lot of activity on the system,
multipathd may not start up immediately, causing block device
initialization to be delayed, potentially until after systemd times
waiting for the device.  To avoid this, multipath now checks if
multipathd is running by reading /run/multipathd.pid and checking the
/proc/<pid>/comm to verify that multipathd is really running with this
pid. This avoids forcing "multipath -u" to wait on multipathd starting
up.

As an alternative to this patch, multipath could simply switch the order
of the calls to systemd_service_enabled() and mpath_connect(). This would
make multipath only try to connect with multipathd if it wasn't enabled in
systemd, so that it wouldn't autostart.

Another alternative is to do away with multipathd.socket. Since multipathd
needs to always be running in order to get uevents, there isn't much value
in having it autoactivate when it gets an interactive command.

Signed-off-by: Benjamin Marzinski <bmarzins@redhat.com>
multipath/main.c