Re: [PATCH 4/4] multipathd: print path offline message even without a checker

[Benjamin Marzinski <bmarzins@redhat.com>]

On Wed, Jan 21, 2026 at 10:00:21AM +0100, Martin Wilck wrote:
> On Tue, 2026-01-20 at 23:23 -0500, Benjamin Marzinski wrote:
> > If a path has a checker selected and is offline, multipathd will
> > print a
> > "path offline" message. However if the checker isn't selected, for
> > instance because multipathd was started or reconfigured while the
> > path
> > was offline, multipathd was not printing the "path offline" message.
> > Fix that.
> > 
> > Signed-off-by: Benjamin Marzinski <bmarzins@redhat.com>
> > ---
> >  multipathd/main.c | 5 ++---
> >  1 file changed, 2 insertions(+), 3 deletions(-)
> > 
> > diff --git a/multipathd/main.c b/multipathd/main.c
> > index 2140e432..69e4808f 100644
> > --- a/multipathd/main.c
> > +++ b/multipathd/main.c
> > @@ -96,12 +96,11 @@ mpath_pr_event_handle(struct path *pp, unsigned
> > int nr_keys_needed,
> >  
> >  #define LOG_MSG(lvl, pp)					\
> >  do {								\
> > -	if (pp->mpp && checker_selected(&pp->checker) &&	\
> > -	    lvl <= libmp_verbosity)
> > {					\
> > +	if (pp->mpp && lvl <= libmp_verbosity) {		\
> >  		if (pp->sysfs_state == PATH_DOWN)		\
> 
> While at it, we should probably change this to "p->sysfs_state !=
> PATH_UP", because start_path_check will only call the checker for the
> PATH_UP case, and in other cases, the checker state will be stale.

Sure, although I'm pretty sure that will just mean that removed paths
might see a final log message, since PATH_PENDING paths won't see any,
and the only other sysfs_state options are PATH_UP and PATH_DOWN.
Actually, if we print an explicit "path removed" message, it could be
useful on the off chance that a removed path didn't transistion to
INIT_REMOVED like it should.

-Ben
 
> Regards,
> Martin