From: Kiyoshi Ueda <k-ueda@ct.jp.nec.com>
To: Benjamin Marzinski <bmarzins@redhat.com>
Cc: device-mapper development <dm-devel@redhat.com>
Subject: Re: [PATCH] multipath: don't let init script stop multipathd for root devices
Date: Tue, 30 Mar 2010 09:11:13 +0900 [thread overview]
Message-ID: <4BB141A1.3070402@ct.jp.nec.com> (raw)
In-Reply-To: <20100326162340.GI23952@ether.msp.redhat.com>
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
next prev parent reply other threads:[~2010-03-30 0:11 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-25 17:52 [PATCH] multipath: don't let init script stop multipathd for root devices Benjamin Marzinski
2010-03-26 2:04 ` Kiyoshi Ueda
2010-03-26 16:23 ` Benjamin Marzinski
2010-03-30 0:11 ` Kiyoshi Ueda [this message]
2010-04-01 18:42 ` Benjamin Marzinski
2010-04-02 2:20 ` Kiyoshi Ueda
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4BB141A1.3070402@ct.jp.nec.com \
--to=k-ueda@ct.jp.nec.com \
--cc=bmarzins@redhat.com \
--cc=dm-devel@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.