[dm-devel] [PATCH] multipath: don't let init script stop multipathd for root devices

Kiyoshi Ueda k-ueda at ct.jp.nec.com
Tue Mar 30 00:11:13 UTC 2010


Hi Ben,

On 03/27/2010 01:23 AM +0900, Benjamin Marzinski wrote:
> On Fri, Mar 26, 2010 at 11:04:22AM +0900, Kiyoshi Ueda wrote:
>> Hi Ben,
>>
>> On 03/26/2010 02:52 AM +0900, Benjamin Marzinski wrote:
>>> This patch modifies the redhat init script, so that it doesn't allow
>>> multipathd to be stopped when the root device is on it.
>> Why do you need to prevent stopping daemon by script-level forcibly?
>> I think that users/developers may want to restart the daemon at their
>> own risk when it starts to behave something wrong or they change
>> a configuration (since "reconfigure" may not be stable feature).
>>
>> # Maybe others have different opinion but I often use "restart".
>>
>> If you need this patch anyway, please add other options to stop/restart
>> the daemon forcibly.  (e.g. adding force-stop/force-restart)
> 
> I can certainly add a force-stop/force-restart.  This can currently be
> accomplished by simply killing the daemon, but admittedly doing it
> through the init script is cleaner and more obvious to users, and it's
> necessary to allow package upgrades to immediately start using
> multipathd on systems with multipathed root disks.
> 
> However, what is there that you need to restart the daemon for that
> 
> # service multipathd reload
> 
> won't fix, besides upgrading the package.  If there is something, then
> we should fix it.  I only stop the daemon when I'm testing shutting
> down, and upgrading source. Otherwise, I've been using reconfigure
> without problems.

I may be confusing you.
I know/understand that current reconfigure works well and if it doesn't
work we should fix it.

My point is that "why do you need to prevent stopping daemon
by script-level forcibly?".
As you mentioned above, killing the daemon through the init script
is cleaner and more obvious.  So I think leaving something to stop
the daemon in the init script is more friendly for admins.

Thanks,
Kiyoshi Ueda




More information about the dm-devel mailing list