On Mon, 2022-03-21 at 19:43 -0500, Benjamin Marzinski wrote: > On Fri, Mar 18, 2022 at 5:33 PM <mwilck@xxxxxxxx> wrote: > > > > From: Martin Wilck <mwilck@xxxxxxxx> > > > > These messages are noisy in the system log without being actually > > helpful. > > I've actually found the "start up" and "shut down" messages useful a > number of times, for tracking when multipathd starts up and shuts > down. Makes sense ;-) Currently we see the following messages for multipathd startup and shutdown: Mar 11 09:30:00 bremer systemd[1]: Starting Device-Mapper Multipath Device Controller. Mar 11 09:30:01 bremer multipathd[363]: --------start up-------- Mar 11 09:30:01 bremer systemd[1]: Started Device-Mapper Multipath Device Controller. Mar 11 09:30:01 bremer multipathd[363]: read /etc/multipath.conf Mar 11 09:30:01 bremer multipathd[363]: path checkers start up ... Mar 11 09:30:52 bremer systemd[1]: Stopping Device-Mapper Multipath Device Controller... Mar 11 09:30:52 bremer multipathd[363]: exit (signal) Mar 11 09:30:52 bremer multipathd[363]: --------shut down------- Mar 11 09:30:52 bremer systemd[1]: Stopped Device-Mapper Multipath Device Controller. To my taste, this is too much. Of course, not everyone is using systemd. Without systemd and with the part of my patch you acked, we'd be down from 9 to 3 messages. IMO either the "exit" message or the "shut down" message could be hidden at -v2. I suppose we could decrease the verbosity level of handle_signals() to -v3 instead. Would you agree with that? > Since people generally run multipathd constantly, they rarely > appear more than a couple of times per boot. I would prefer if they > could stay. I'm fine with removing the others. Ok, fine with me. Do you insist on the "--------", too? It's mainly that which bothers me. If you look at the typical boot messages of contemporary Linux servers, no other daemon uses this strong emphasis for an informational message. The informational value would be higher if we printed a detailed version number including HEAD commit ID, like other daemons do. Martin -- dm-devel mailing list dm-devel@xxxxxxxxxx https://listman.redhat.com/mailman/listinfo/dm-devel
