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

[Christophe Varoqui <christophe.varoqui@free.fr>]

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


--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel