[Nut-upsuser] upsmon shutdown on stale data

[Michael Hughes]

On Wed, 24 Dec 2025 19:06:03 +0100
Jim Klimov <jimklimov+nut at gmail.com> wrote:

>
> 
> 
> On Wed, Dec 24, 2025 at 3:39 PM Michael Hughes via Nut-upsuser <
> nut-upsuser at alioth-lists.debian.net> wrote:
> 
> > On Wed, 24 Dec 2025 12:02:15 +0100
> > Jim Klimov <jimklimov+nut at gmail.com> wrote:  
> > > > I'm having problems with one of my UPS (BEST MD500), the upsd
> > > > has stale data, we get a power hit and upsmon give the following
> > > > message:
> > > >
> > > > upsmon[918]: UPS [UPS1 at localhost] was last known to be not fully
> > > > online and currently is not communicating, assuming dead
> > > >
> > > > upsmon starts a shutdown and then upsd gives a data is no longer
> > > > stale, but the shutdown still happens.  Or a way to have upsmon
> > > > wait awhile before starting the shutdown?
> > > >
> > > > Is there someway to stop the shutdown when this happens?  I'm
> > > > still debugging why the driver is loosing communication with
> > > > the UPS. --
> > > > Michael
> > > > _______________________________________________
> > > > Nut-upsuser mailing list
> > > > Nut-upsuser at alioth-lists.debian.net
> > > > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
> > > >  
> > > Cheers, and happy holidays.
> > >
> > >   I am not sure your logs here show the whole picture. For upsmon
> > > to behave this way, thee must have been a power event and the
> > > driver told the data server the UPS is on battery. Pollfreq
> > > increases too (time delay decreases). If the UPS connection gets
> > > lost then, this is deemed immediately critical as we don't know
> > > how long the system can be up. Maybe battery is old and does not
> > > fit its spec or latest calibration. So we issue FSD to save as
> > > much as we can ASAP.
> > >
> > >   Need to check in code if there are now any throttle toggles for
> > > this.
> > >
> > >   And then if shutdown did begin, generally the only way to bring
> > > the system back up consistently is to reboot it one way or
> > > another. Your custom SHUTDOWNCMD implementation may do whatever
> > > fits your case though.
> > >
> > > Hope this helps,
> > > Jim Klimov
> > >
> > >
> > > On Tue, Dec 23, 2025, 21:54 Michael Hughes via Nut-upsuser <
> > > nut-upsuser at alioth-lists.debian.net> wrote:
> > >  
> >
> > Jim,
> > Yes, there was a power outage message before the lost communication.
> >
> > I had thought about changing the poll interval since the
> > communication is done through RS-232.
> >
> >
> > --
> > Michael
> > _______________________________________________
> > Nut-upsuser mailing list
> > Nut-upsuser at alioth-lists.debian.net
> > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
> >  
> So, I got to a computer tonight to check for a bit more detail:
> 
> * the higher-frequency polling is POLLFREQALERT setting. By built-in
> default (if not configured) it is actually same as POLLFREQ default,
> both at 5 sec.
>
> * the FSD upon connection loss is issued in several cases, some
> unilaterally, others can be managed by options like ALARMCRITICAL 0
> (UPS lost while an ALARM of whatever nature was raised)
>
> * the message wording "was last known to be not fully online and
> currently is not communicating, assuming dead" is not present in
> current NUT code base; instead it now reports waiting for DEADTIME to
> expire - see
> https://github.com/networkupstools/nut/blame/master/clients/upsmon.c#L1544-L1548
> and dig history from there to your installed NUT version ** Message
> introduced at
> https://github.com/networkupstools/nut/commit/2647f026f7f0c856926da67cec845a09bed2a5d1
> for https://github.com/networkupstools/nut/issues/2104 and released
> in NUT v2.8.1 ** Changed to current in several PRs and commits,
> finally in
> https://github.com/networkupstools/nut/commit/82e5932d9c4b589856746d31835ee50da3185ce8
> for https://github.com/networkupstools/nut/issues/2454 I think, and
> released in NUT v2.8.3
> 
> By cursory look, maaaybe those issues discuss the problems you saw,
> from another point of view. At least if you have NUT v2.8.1 or v2.8.2
> there.
> 
> Jim

Jim,
I am running 2.8.2 of NUT, and the message is in the source I have and
is in upsmon.c.  The if statement for it start at line 1092.  The
message is on two lines, so if you were looking for the whole string
you wouldn't have found it.

I will look at ALARMCRITICAL and see if this would make a difference.

Thanks for looking!

-- 
Michael
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP digital signature
URL: <http://alioth-lists.debian.net/pipermail/nut-upsuser/attachments/20251225/611a9ae3/attachment.sig>