nut-2.8.2 does not seem to honor DEADTIME

[avg-I]

nut-2.8.2 does not seem to honor DEADTIME

[jimklimov]

Fair point, at least for the non-critical OB state. Would you care to post a PR for the new toggle?

For a bit more context about the current/default behavior, note however that as an UPS or its batteries age, the original assumptions of what would comprise an actual critical state can become obsolete (part of why some devices offer calibration functionality). So based on invalid assumptions we can think there's a lot of juice in the battery, while in fact the UPS is a glorified power strip or close to that.

[jimklimov]

I suppose "link down/up" transitions broke the TCP session, so the upsmon client was forcefully disconnected from the upsd data server while in a critical state, and behaved by design.

[avg-I]

So, any communication problem between upsd and upsmon while on battery, and upsmon is supposed to immediately start powering off?

Then, what DEADTIME is for?

# DEADTIME - Interval to wait before declaring a stale ups "dead"
# 
# upsmon requires a UPS to provide status information every few seconds
# (see POLLFREQ and POLLFREQALERT) to keep things updated.  If the status
# fetch fails, the UPS is marked stale.  If it stays stale for more than
# DEADTIME seconds, the UPS is marked dead.
# 
# A dead UPS that was last known to be on battery is assumed to have gone
# to a low battery condition.  This may force a shutdown if it is providing
# a critical amount of power to your system.

Is that applicable only to a local (serial or USB connected) UPS?
Is there any control like that for network communication?

[jimklimov]

The data server regularly updates the connected clients like upsmon with broadcasts about device information. For your corner case, "connected" is the critical word. Link flickered, IP address probably disappeared for a few seconds, TCP session got broken, server is assumed abruptly powered off (and/or its OS went down without waiting for clients to disconnect, so its upsd is off). And since the UPS was last known to be on battery, we haven't got much more time to reconnect or investigate either. To keep data safe, gotta run to stop services, flush filesystems ASAP.

This seems similar to the documented example with networking gear turning off because it is not on an UPS (or a weaker one) and that being among the reasons for emergency shutdown of a client. Here your lack of network just did not have some switch or router disappearing.

[avg-I]

I see your point.

At the same time, the UPS was not really critical, it was on battery but not low battery.

It would be nice if users had some control over the behavior.
Immediate shutdown on any glitch is not suitable for all.
In some scenarios a UPS is used just to give enough time for an orderly shutdown.
But in other scenarios people want to keep services running for as long as possible (e.g., with regularly scheduled blackouts).

We give the master server DEADTIME to restore communications with a UPS device.
But we do not give slaves any time to restore communications with the master.
Seems like an omission.