-
-
Notifications
You must be signed in to change notification settings - Fork 334
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
nut-2.8.2 does not seem to honor DEADTIME #2454
Comments
I suppose "link down/up" transitions broke the TCP session, so the |
So, any communication problem between upsd and upsmon while on battery, and upsmon is supposed to immediately start powering off? Then, what
Is that applicable only to a local (serial or USB connected) UPS? |
The data server regularly updates the connected clients like 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. |
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. We give the master server |
Fair point, at least for the non-critical 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 created #2462. Not sure if that matches your idea on how the issue should be resolved. |
…he log warning message [networkupstools#2454] Signed-off-by: Jim Klimov <jimklimov+nut@gmail.com>
…ls#2462 Signed-off-by: Jim Klimov <jimklimov+nut@gmail.com>
…ls#2462 Signed-off-by: Jim Klimov <jimklimov+nut@gmail.com>
…he log warning message [networkupstools#2454] Signed-off-by: Jim Klimov <jimklimov+nut@gmail.com>
Primary PR merged. Exploratory one (to return the log message) left out for now, per discussion. Maybe will come back to it for debug-only logging just in case, though. |
…he debug log message [networkupstools#2454] Signed-off-by: Jim Klimov <jimklimov+nut@gmail.com>
Just reading up on this some more after being out and about for a while. I agree a criticality should not be triggered by a minor communication staleness even when In any case, I'm always happy with user-configurability where it makes sense (and especially for shutdown criteria), and instant criticality might have indeed been a bit too strict here in retrospect (but with good intentions nonetheless). |
I have a single UPS and several computers powered off it.
One is a master that runs upsd and upsmon, others are slaves that run just upsmon.
Here is a snippet from upsmon.conf on one of the slaves:
Recently, during a blackout, I had a glitch where the network interface on that slave went down for about 4 seconds.
Its upsmon started powering off the machine in about 5 seconds, which was not ideal in the situation.
Here are some logs:
I expected that upsmon would wait for
DEADTIME
before doing that.What additional information should I provide?
The text was updated successfully, but these errors were encountered: