How to stop global/root broadcast from NUT services

[SomebodySysop]

I have NUT running on an older PC with only 2.0 USB ports. I get "BADCOMM" and "NOCOMM" errors frequently, resulting in "Stale data" messages on the web monitor. To combat this, I commented out those notify flags, and I restart the NUT driver /sbin/upsdrvctl start on this machine every 15 minutes. This results in the following messages being broadcast to the console at each restart:

Broadcast message from root@ContaCam01-Ubuntu (somewhere) (Mon Dec 20 22:30:10                                                                                
Communications with UPS cyberpower-j@localhost established       

These are the corresponding messages in the syslog:

Dec 20 22:30:07 ContaCam01-Ubuntu upsd[924]: Connected to UPS [cyberpower-j]: usbhid-ups-cyberpower-j
Dec 20 22:30:10 ContaCam01-Ubuntu upsmon[927]: Communications with UPS cyberpower-j@localhost established

I have my upsmon.conf configured to NOT include WALL messages:

# Email script for NOTIFYCMD
NOTIFYCMD "/etc/nut/notifycmd.sh"
# Notification events
NOTIFYFLAG ONLINE     SYSLOG+EXEC
NOTIFYFLAG ONBATT     SYSLOG+EXEC
NOTIFYFLAG LOWBATT    SYSLOG+EXEC
NOTIFYFLAG FSD        SYSLOG+EXEC
# NOTIFYFLAG COMMOK     SYSLOG+EXEC
# NOTIFYFLAG COMMBAD    SYSLOG+EXEC
NOTIFYFLAG SHUTDOWN   SYSLOG+EXEC
NOTIFYFLAG REPLBATT   SYSLOG+EXEC
# NOTIFYFLAG NOCOMM     SYSLOG+EXEC
NOTIFYFLAG NOPARENT   SYSLOG+EXEC

Apparently, getting rid of "WALL" doesn't stop these messages from being broadcast when driver is restarted. These messages get in the way when I'm trying to edit files or working on other things. Any suggestions on how to stop them from being broadcast to my console?

[jimklimov]

Looking at the sources, "Communications with UPS..." is passed to upslogx() routine and the message ends up with the syslog daemon. Then it depends on routing setup in that daemon - whether the message is only stored, or if for some urgency levels it is also broadcast.

In the code, the recurring pattern is that "LOG_NOTICE" happens for "comms established", and "LOG_WARNING" for "comms lost".

[SomebodySysop]

Looking at the sources, "Communications with UPS..." is passed to upslogx() routine and the message ends up with the syslog daemon. Then it depends on routing setup in that daemon - whether the message is only stored, or if for some urgency levels it is also broadcast.

In the code, the recurring pattern is that "LOG_NOTICE" happens for "comms established", and "LOG_WARNING" for "comms lost".

Any way to still run the programs but turn off these broadcast messages?

[jimklimov]

Configure your syslog daemon? For rsyslogd, you can quite flexibly match message contents to route them Alternately, you can probably edit and rebuild NUT sources to define different logging levels for those messages (server/upsd.c etc.) or mapping of upslogx parameters to syslog levels (common/common.c IIRC)

…

On Tue, Dec 21, 2021, 22:51 SomebodySysop ***@***.***> wrote: Looking at the sources, "Communications with UPS..." is passed to upslogx() routine and the message ends up with the syslog daemon. Then it depends on routing setup in that daemon - whether the message is only stored, or if for some urgency levels it is also broadcast. In the code, the recurring pattern is that "LOG_NOTICE" happens for "comms established", and "LOG_WARNING" for "comms lost". Any way to still run the programs but turn off these broadcast messages? — Reply to this email directly, view it on GitHub <#1231 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAMPTFH5KMO2JH646PPNVHDUSDZFFANCNFSM5KPRQBBQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you commented.Message ID: ***@***.***>

[jimklimov]

One more thing, a particular user account's shell preference may include mesg n to avoid receiving such broadcasts. This may be configured separately for each session (e.g. older X11 setups kept one explicit "console" terminal to receive such sysadmin messages and other terminals were not polluted by default).

[gdt]

This seems like not a bug in nut, and therefore should probably be just closed.

[jimklimov]

Actually, while revising this question now, I noticed it mentions Cyberpower UPSes and regular reconnections. This rings a bell nowadays - @SomebodySysop please follow the CPS label for (possibly closed) issues.

Some of those models were known to disconnect the port (e.g. if polling was too rare, IIRC) for power-saving, and then the OS re-discovered the connection and kernel grabbed the device node. Some funky interactions between kernel, udev and driver ensued... or not.

Also can recommend custom-building NUT from recent GitHub sources -- during the last year general reconnection logic was addressed in some PRs, so now might work (or log itself) better, as well as more intensive killing of an older driver instance when a newer one starts (to more surely grab the device/port). Also 2.8.0 and current git include better systemd integration than 2.7.4 or earlier had (which are still delivered as packages by some distros).