Bug#817940: multipath-tools: multipathd is not linked to libsystemd, fails to notify systemd when ready
Hello Ryan, Thank you for the root cause and the patch. I have applied, built and verified it. It will be part of the next upload. Thanks, Ritesh On Fri, 2016-03-11 at 13:05 -0600, Ryan Harper wrote: > 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 (0x7ffd25ba4000) > libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 > (0x7f2a316b4000) > libdevmapper.so.1.02.1 => /lib/x86_64-linux- > gnu/libdevmapper.so.1.02.1 (0x7f2a31458000) > libreadline.so.6 => /lib/x86_64-linux-gnu/libreadline.so.6 > (0x7f2a3120d000) > libudev.so.1 => /lib/x86_64-linux-gnu/libudev.so.1 > (0x7f2a311ed000) > libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 > (0x7f2a30fe9000) > libmultipath.so.0 => /lib/libmultipath.so.0 > (0x7f2a30d9c000) > libmpathpersist.so.0 => /lib/libmpathpersist.so.0 > (0x7f2a30b94000) > libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 > (0x7f2a307f) > /lib64/ld-linux-x86-64.so.2 (0x5603084da000) > librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 > (0x7f2a305e7000) > libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1 > (0x7f2a303c5000) > libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 > (0x7f2a300c) > libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5 > (0x7f2a2fe95000) > libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 > (0x7f2a2fc25000) > > > 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
Bug#817940: multipath-tools: multipathd is not linked to libsystemd, fails to notify systemd when ready
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 (0x7ffd25ba4000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x7f2a316b4000) libdevmapper.so.1.02.1 => /lib/x86_64-linux-gnu/libdevmapper.so.1.02.1 (0x7f2a31458000) libreadline.so.6 => /lib/x86_64-linux-gnu/libreadline.so.6 (0x7f2a3120d000) libudev.so.1 => /lib/x86_64-linux-gnu/libudev.so.1 (0x7f2a311ed000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f2a30fe9000) libmultipath.so.0 => /lib/libmultipath.so.0 (0x7f2a30d9c000) libmpathpersist.so.0 => /lib/libmpathpersist.so.0 (0x7f2a30b94000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f2a307f) /lib64/ld-linux-x86-64.so.2 (0x5603084da000) librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x7f2a305e7000) libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1 (0x7f2a303c5000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f2a300c) libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5 (0x7f2a2fe95000) libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x7f2a2fc25000) 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.0 -0600 +++
