On Wed, 2023-10-25 at 19:58 -0400, Benjamin Marzinski wrote: > On Tue, Oct 24, 2023 at 06:49:37PM +0200, [email protected] wrote: > > From: Martin Wilck <[email protected]> > > > > 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 <[email protected]> > > 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 <[email protected]>
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
