On Wed, 2026-01-21 at 11:02 -0500, Benjamin Marzinski wrote: > 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.
I'm fine with always printing "offline" here, which at that point would just mean that no checker state could be retrieved. Martin
