Is it o.k. if multipathd simply prints a well defined message to the system logs when it notices that multipath.conf has been modified? If users need more obvious notifications, they would need something that watches the logs for this message and generates the notifications that they want.

(In reply to Ben Marzinski from comment #1)
> Is it o.k. if multipathd simply prints a well defined message to the system
> logs when it notices that multipath.conf has been modified? If users need
> more obvious notifications, they would need something that watches the logs
> for this message and generates the notifications that they want.

Hi Ben,

will this log a message once when multipath.conf is changed, and regardless of whether multipathd has been reloaded or not?

We're trying to warn users when they forget to reload multipath after changing multipath.conf . It's doubtful they'd be monitoring the logs for something they forgot to do in the first place.. 

but I guess printing a message to the logs each time a multipath command is subsequently run (only if multipath.conf was changed AND multipathd not reloaded since then) might be a possibility, instead of just once when the multipath.conf is changed?

What do you think ?

Yes, it logs as soon as multipath.conf or a file the config directory is changed. So clearly, at that point multipathd hasn't been reloaded yet.  Multipathd has always logged when it has been reloaded.

So, my actual thought was that this would give people the ability to track this by syslog/journald monitoring software and issue notifications. I'm not sure if redhat ships any packages that do this easily, but they certainly exist, and if we don't currently have a recommended method(s) for monitoring the logs and sending out notifications, we should. A quick search shows

https://github.com/eworm-de/journal-notify
https://github.com/djmattyg007/journald-notify

along with multiple commercial programs for log monitoring and notification. I have no problem with making multipath print out a warning message if it is run and multipathd needs to be reloaded. That makes sense.

It turns out to be significantly more work to track the state of multipath.conf from multipath, since it's not a daemon, and I don't really want to add more connections between multipath and multipathd than necessary, just for this.  I am moving this bug to Modified, since I want to keep the changes already done here. In the future, I can look at having multipathd tracking the multipath.conf state by some method that multipath can query, likely a file in /var/run. But that can happen with a different bug, since I want to use this one to push in the changes for multipathd to get notifications on configuration changes, and to log them.

Verified on device-mapper-multipath-0.8.3-2.el8
[root@storageqe-25 ~]# rpm -qa | grep multipath
device-mapper-multipath-libs-0.8.3-2.el8.x86_64
device-mapper-multipath-0.8.3-2.el8.x86_64


[root@storageqe-25 ~]# multipath -ll
360a98000324669436c2b45666c567861 dm-5 NETAPP,LUN
size=2.0G features='3 queue_if_no_path pg_init_retries 50' hwhandler='1 alua' wp=rw
|-+- policy='service-time 0' prio=50 status=active
| |- 3:0:1:2 sdh 8:112 active ready running
| `- 8:0:1:2 sdp 8:240 active ready running
`-+- policy='service-time 0' prio=10 status=enabled
  |- 3:0:0:2 sdd 8:48  active ready running
  `- 8:0:0:2 sdl 8:176 active ready running
360a98000324669436c2b45666c567858 dm-3 NETAPP,LUN
size=2.0G features='3 queue_if_no_path pg_init_retries 50' hwhandler='1 alua' wp=rw
|-+- policy='service-time 0' prio=50 status=active
| |- 3:0:1:0 sdf 8:80  active ready running
| `- 8:0:1:0 sdn 8:208 active ready running
`-+- policy='service-time 0' prio=10 status=enabled
  |- 3:0:0:0 sdb 8:16  active ready running
  `- 8:0:0:0 sdj 8:144 active ready running
360a98000324669436c2b45666c567863 dm-6 NETAPP,LUN
size=2.0G features='3 queue_if_no_path pg_init_retries 50' hwhandler='1 alua' wp=rw
|-+- policy='service-time 0' prio=50 status=active
| |- 3:0:1:3 sdi 8:128 active ready running
| `- 8:0:1:3 sdq 65:0  active ready running
`-+- policy='service-time 0' prio=10 status=enabled
  |- 3:0:0:3 sde 8:64  active ready running
  `- 8:0:0:3 sdm 8:192 active ready running
360a98000324669436c2b45666c56785a dm-4 NETAPP,LUN
size=2.0G features='3 queue_if_no_path pg_init_retries 50' hwhandler='1 alua' wp=rw
|-+- policy='service-time 0' prio=50 status=active
| |- 3:0:1:1 sdg 8:96  active ready running
| `- 8:0:1:1 sdo 8:224 active ready running
`-+- policy='service-time 0' prio=10 status=enabled
  |- 3:0:0:1 sdc 8:32  active ready running
  `- 8:0:0:1 sdk 8:160 active ready running

modify /etc/multipath.conf
[root@storageqe-25 ~]# vim /etc/multipath.conf
defaults {
        user_friendly_names yes
        find_multipaths yes
#       path_grouping_policy failover   <--------------------modify /etc/multipath.conf
}


Check /var/log/messages
[root@storageqe-25 ~]# vim /var/log/messages
Nov 28 21:01:05 storageqe-25 multipathd[37752]: Multipath configuration updated.
Nov 28 21:01:05 storageqe-25 multipathd[37752]: Reload multipathd for changes to take effect
<------------------------------------------multipathd logs above message

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2020:1868