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 <[email protected]> > > --- > > 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
