On Wed, 2023-10-25 at 19:58 -0400, Benjamin Marzinski wrote:
> On Tue, Oct 24, 2023 at 06:49:37PM +0200, mwilck@xxxxxxxx wrote:
> > From: Martin Wilck <mwilck@xxxxxxxx>
> >
> > Since c203929 ("multipathd.service: add dependency on
> > systemd-udevd-kernel.socket"), multipathd will start early during
> > boot.
> > Moreover, we recommend using socket activation for multipathd,
> > and if multipathd.socket is enabled, the __mpath_connect()
> > check will succeed anyway.
> >
> > The systemd_service_enabled() test was just "good enough" for
> > standard situations but never robust; it checked for
> > multipathd.wants in
> > "some" directory, which might or might not be the current target,
> > and it would return true even of multipathd.service was masked.
> >
> > Remove this test.
> >
> > Signed-off-by: Martin Wilck <mwilck@xxxxxxxx>
>
> I'd be lying if I said I had no worries at all about this. Removing
> this
> check means that if someone isn't using socket activation, and
> multipathd is temporarily down, and a new device appears, it will
> always
> be marked as not claimed by multipath. This could cause the device to
> be
> grabbed by LVM, and not multipathed. This is probably just may
> paranoia
> talking, since the chance of this happening in the real world seems
> pretty low. So,
>
> Reviewed-by: Benjamin Marzinski <bmarzins@xxxxxxxxxx>
Thanks. I had the same doubts, but I came to the conclusion that
there's no need to be afraid.
I would put your argument a bit differently: If socket activation is
not used and multipathd is not running, we are in a situation where
multipath can't seriously claim any device. Whether multipathd is
enabled in some (apparently inactive) systemd target doesn't really
matter in such a situation. Note that we never checked _which_ systemd
unit lists multipathd under its ".wants". It could be
"shutdown.target".
Martin
