Package: multipath-tools
Version: 0.5.0+git1.656f8865-5
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu xenial ubuntu-patch

Dear Maintainer,

When installing multipath-tools package on Debian stretch/sid, the package fails
to start.

Setting up kpartx (0.5.0+git1.656f8865-5) ...
Setting up multipath-tools (0.5.0+git1.656f8865-5) ...
Job for multipathd.service failed because the control process exited with error
code. See "systemctl status multipathd.service" and "journalctl -xe" for
details.
invoke-rc.d: initscript multipath-tools, action "start" failed.
dpkg: error processing package multipath-tools (--configure):
subprocess installed post-installation script returned error exit status 1


Looking at systemctl status -l multipathd  we can see that the service timed
out and gets killed.  However, during this start-up period, multipathd is
functional, one can issue multipath -ll and other commands.


# systemctl status multipathd
● multipathd.service - Device-Mapper Multipath Device Controller
   Loaded: loaded (/lib/systemd/system/multipathd.service; enabled; vendor prese
   Active: failed (Result: timeout) since Fri 2016-03-11 13:00:03 CST; 14s ago
 Main PID: 1176 (code=exited, status=0/SUCCESS)

Mar 11 12:58:33 debian systemd[1]: Starting Device-Mapper Multipath Device Contr
Mar 11 12:58:33 debian multipathd[1176]: could not create uxsock: 98
Mar 11 12:58:33 debian multipathd[1176]: path checkers start up
Mar 11 13:00:03 debian systemd[1]: multipathd.service: Start operation timed out
Mar 11 13:00:03 debian multipathd[1176]: --------shut down-------
Mar 11 13:00:03 debian systemd[1]: Failed to start Device-Mapper Multipath Devic
Mar 11 13:00:03 debian systemd[1]: multipathd.service: Unit entered failed state
Mar 11 13:00:03 debian systemd[1]: multipathd.service: Failed with result 'timeo


The systemd service file for multipathd uses Type=notify which means that
multipathd will issue sd_notify() calls via libsystemd linkage to systemd itself
to indicate when it is ready.

Using ldd to examine /sbin/multipathd and it does not show a link to libsystemd.

root@debian:~# ldd /sbin/multipathd  | grep systemd
root@debian:~# ldd /sbin/multipathd 
        linux-vdso.so.1 (0x00007ffd25ba4000)
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 
(0x00007f2a316b4000)
        libdevmapper.so.1.02.1 => /lib/x86_64-linux-gnu/libdevmapper.so.1.02.1 
(0x00007f2a31458000)
        libreadline.so.6 => /lib/x86_64-linux-gnu/libreadline.so.6 
(0x00007f2a3120d000)
        libudev.so.1 => /lib/x86_64-linux-gnu/libudev.so.1 (0x00007f2a311ed000)
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f2a30fe9000)
        libmultipath.so.0 => /lib/libmultipath.so.0 (0x00007f2a30d9c000)
        libmpathpersist.so.0 => /lib/libmpathpersist.so.0 (0x00007f2a30b94000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f2a307f0000)
        /lib64/ld-linux-x86-64.so.2 (0x00005603084da000)
        librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f2a305e7000)
        libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1 
(0x00007f2a303c5000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f2a300c0000)
        libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5 
(0x00007f2a2fe95000)
        libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x00007f2a2fc25000)


This is a result of the debian/rules file which attempts to build multipathd
twice, once with USE_SYSTEMD=1 (for the system) and USE_SYSTEMD=1 for the udeb
packaging (for the debian installer).

Looking closely at a build-log of the package, we can see that when run the
rule 'build-stamp', we invoke make with USE_SYSTEMD=1, however, make does not
find that any of the files in the tree have been modified and does not bother
to recompile any of the packages.

In Ubuntu, the attached patch was applied to achieve the following:

  * debian/rules: add clean-tree to build-stamp to ensure multipathd
    builds with USE_SYSTEMD=1

The simplest, (though maybe not optimal) fix was to have build-stamp depend on
clean-tree target which will run make clean prior to building multipath-tools
with the USE_SYSTEMD=1 and ulimately have multipathd link against libsystemd.

The result is now that multipathd.service can start properly.

Thanks for considering the patch.


-- System Information:
Debian Release: stretch/sid
  APT prefers xenial-updates
  APT policy: (500, 'xenial-updates'), (500, 'xenial-security'), (500, 
'xenial'), (100, 'xenial-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.4.0-7-generic (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
Init: systemd (via /run/systemd/system)
diff -Nru multipath-tools-0.5.0+git1.656f8865/debian/rules multipath-tools-0.5.0+git1.656f8865/debian/rules
--- multipath-tools-0.5.0+git1.656f8865/debian/rules	2016-03-04 07:41:25.000000000 -0600
+++ multipath-tools-0.5.0+git1.656f8865/debian/rules	2016-03-11 08:57:09.000000000 -0600
@@ -29,7 +29,7 @@
 build-arch: build-multipath-udeb-stamp build-stamp
 build-indep: 
 
-build-stamp:
+build-stamp: clean-tree
 	dh_testdir
 	
 	[ ! -f kpartx/kpartx.rules ] || cp kpartx/kpartx.rules debian/kpartx.udev

Reply via email to