On Tue, Mar 04, 2025 at 09:26:12PM +0100, Martin Wilck wrote:
> On Mon, 2025-03-03 at 14:42 -0500, Benjamin Marzinski wrote:
> > On Thu, Feb 27, 2025 at 06:41:04PM +0100, Martin Wilck wrote:
> > > Since c9689b6 ("multipathd: Remove dependency on
> > > systemd-udev-settle.service"), multipathd.service starts very early
> > > during
> > > boot, which in systemd's service ordering logic means that it is
> > > stopped
> > > late. While this is generally a good thing, it means that, when
> > > systemd
> > > unmounts file systems and tears down the block device stack,
> > > multipathd
> > > is still running. Therefore our "queue_without_daemon" logic, which
> > > disables
> > > queuing when multipathd exits, isn't effective yet. If there are
> > > any
> > > multipath maps that are in queueing state at this point in time,
> > > the system
> > > may hang indefinitely.
> > >
> > > To fix that, add a new service which starts later (and thus stops
> > > earlier) and
> > > disables queueing on all multipath maps during shutdown. Similar to
> > > lvm2's
> > > blk-availability.service, the service does nothing when started.
> > >
> > > Fixes: c9689b6 ("multipathd: Remove dependency on systemd-udev-
> > > settle.service")
> >
> > Reviewed-by: Benjamin Marzinski <bmarzins@xxxxxxxxxx>
>
> Thanks - do you reckon this is suitable for the stable tree?
> There is not much of a regression risk, but it requires shipping
> another file, so it's non-trivial for packagers.
>
> Personally I'm inclined to add it to stable (also because I'll need to
> backport it anyway).
I on the fence about this one. It does fix a bug, but adding a new
service is kinda feature-y. But your right that there's not much risk of
it breaking things, so it doesn't really matter much to me either way.
-Ben
>
> Martin
