Bug#817940: multipath-tools: multipathd is not linked to libsystemd, fails to notify systemd when ready

Ryan Harper ryan.harper at canonical.com
Fri Mar 11 19:05:39 UTC 2016


Package: multipath-tools
Version: 0.5.0+git1.656f8865-5
Severity: normal
Tags: patch
User: ubuntu-devel at 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 at debian:~# ldd /sbin/multipathd  | grep systemd
root at 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)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: multipath-tools_0.5.0+git1.656f8865-5ubuntu1.debdiff
Type: text/x-diff
Size: 504 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-lvm-maintainers/attachments/20160311/5cacde1f/attachment.diff>


More information about the pkg-lvm-maintainers mailing list