[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [dm-devel] Fwd: [Next problem with multipath-tools]



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).






[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]