Patrick,
remember me why you can't start the daemon later in the boot process ?
Last time when talked about that I guess we concluded the startup
position didn't really care ...
Anyway, if you maintain the need, several solution might be evaluated :
o a cmdline flag to disable pidfile creation, for those distro that
manage that in the init script
o a different default pidfile location, or a flag to point to a custom
location
o rip the pidfile logic altogether and go for a pidof() thing in the tool
Concerning /var/cache/multipathd, I guess the overlay doesn't matter as
the CLONE_NEWNS flag should protect our namespace.
Please comment on your prefered ways.
Regards,
cvaroqui
Hello Patrick,
I installed the new version of libsysfs1 which fixed problem in location of
libsysfs in /lib (instead in /usr/lib). But I think that this bug fix didn't
solve problem with multipath-tools. After reboot multipathd is able to start
correctly when server is coming up. Unfortunately if /var is located on
separate volume and is mounted at startup sequence after multipathd start, the
new mounted file system will overlay directory structure (located in /var -
i.e. /var/run and /var/cache/multipathd) for multipathd and daemon will stay
nonfunctional. Multipathd is running but do nothing from this moment. It is
necessary to restart multipathd after mounting of /var file system. I have no
idea how to solve this problem (maybe it is necessary to modify multipathd to
store information elsewhere than in /var - i.e. somewhere on root partition or
in ram disk).
