From: Benjamin Marzinski <bmarzins@redhat.com>
To: Martin Wilck <martin.wilck@suse.com>
Cc: "dm-devel@redhat.com" <dm-devel@redhat.com>
Subject: Re: [dm-devel] [PATCH 3/5] multipath: print warning if multipathd is not running.
Date: Mon, 30 Aug 2021 16:28:10 -0500 [thread overview]
Message-ID: <20210830212810.GB3087@octiron.msp.redhat.com> (raw)
In-Reply-To: <a6c0dff1b97512eb4150969894de22c3d2d0efc8.camel@suse.com>
On Thu, Aug 12, 2021 at 10:23:09AM +0000, Martin Wilck wrote:
> On Do, 2021-07-29 at 16:46 -0500, Benjamin Marzinski wrote:
> > If multipath notices that multipath devices exist or were created,
> > and
> > multipathd is not running, it now prints a warning message, so users
> > are
> > notified of the issue.
> >
> > Signed-off-by: Benjamin Marzinski <bmarzins@redhat.com>
>
> I'm not sure about this. Are there zero valid use cases for using
> multipath without multipathd?
There certainly are. That's why I tried to limit the warning to only
cases where the user was creating, reloading, or listing devices and
found/created some. In testing, sure, you might want multipathd
disabled, but in general, if you have multipath devices, you want
multipathd running. If you have it temporarily disabled for some
reason, I don't see much harm in having multipath remind you of that.
> On production systems, I agree,
> multipathd should always be running. Personally wouldn't want to see
> this warning every time I run "multipath" while multipathd is
> (temporarily) disabled. Have you got user requests for this feature?
Well, Support has requested this. Apparently they have repeatedly seen
cases where people don't have any multipath devices present, because
multipathd is not running. They run multipath, the devices appear, and
they move on, unaware that multipathd isn't running for whatever
reason.
> In particular, I dislike the idea of putting this code into
> libmultipath. I would love to get rid of the "is_daemon" logic some
> day. If at all, the detection of the situation and the warning should
> be implemented in multipath, IMO.
Sure. I can rework this to keep the logic inside multipath,
> The message should be prefixed with the word "Warning: " to make sure
> the admin understands that he's supposed to take action.
Makes sense.
-Ben
> Regards,
> Martin
--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman/listinfo/dm-devel
next prev parent reply other threads:[~2021-08-30 21:28 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-29 21:46 [dm-devel] [PATCH 0/5] Mulitpath: miscellaneous patches Benjamin Marzinski
2021-07-29 21:46 ` [dm-devel] [PATCH 1/5] multipath.conf: fix typo in ghost_delay description Benjamin Marzinski
2021-08-12 10:22 ` Martin Wilck
2021-07-29 21:46 ` [dm-devel] [PATCH 2/5] mpathpersist: fail commands when no usable paths exist Benjamin Marzinski
2021-08-12 10:23 ` Martin Wilck
2021-07-29 21:46 ` [dm-devel] [PATCH 3/5] multipath: print warning if multipathd is not running Benjamin Marzinski
2021-08-12 10:23 ` Martin Wilck
2021-08-30 21:28 ` Benjamin Marzinski [this message]
2021-07-29 21:46 ` [dm-devel] [PATCH 4/5] libmultipath: remove unneeded code in coalesce_paths Benjamin Marzinski
2021-08-12 10:23 ` Martin Wilck
2021-07-29 21:46 ` [dm-devel] [PATCH 5/5] libmultipath: deal with dynamic PTHREAD_STACK_MIN Benjamin Marzinski
2021-08-12 10:23 ` Martin Wilck
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=20210830212810.GB3087@octiron.msp.redhat.com \
--to=bmarzins@redhat.com \
--cc=dm-devel@redhat.com \
--cc=martin.wilck@suse.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).