<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>I posted the issue in github here:
<a class="moz-txt-link-freetext" href="https://github.com/networkupstools/nut/issues/2999">https://github.com/networkupstools/nut/issues/2999</a></p>
<p>I am not sure about labels or what else might be required.</p>
<p>Thank you!<br>
</p>
<div class="moz-cite-prefix">On 7/1/25 03:23, Jim Klimov wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAJYg8v+36_5n1yOi78fkc2ao8OHjxGXHMFMsiiD7co5R082+Hw@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">
<div>I think yes, seems like a valid bug.</div>
<div><br>
</div>
<div>Also as you mention `upsdrvctl`, systemd and NUT v2.8.x
together, take a look at <a
href="https://github.com/networkupstools/nut/wiki/nut%E2%80%90driver%E2%80%90enumerator-(NDE)"
moz-do-not-send="true" class="moz-txt-link-freetext">https://github.com/networkupstools/nut/wiki/nut%E2%80%90driver%E2%80%90enumerator-(NDE)</a> -
it may be more applicable to use `upsdrvsvcctl` instead
nowadays.</div>
<div><br>
</div>
<div>Jim</div>
<div><br>
</div>
</div>
<br>
<div class="gmail_quote gmail_quote_container">
<div dir="ltr" class="gmail_attr">On Tue, Jul 1, 2025 at
12:35 AM Vyasa <<a href="mailto:info@dalpha.com"
moz-do-not-send="true" class="moz-txt-link-freetext">info@dalpha.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote"
style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<p>Hi Jim,</p>
<p>Thanks for the prompt response.</p>
<p>The restart I refer to was exactly as you say. Where I
restarted the service using: systemctl restart
nut-server. This was separate to where I mention the
reboot of server machine, which resolves the issue.<br>
</p>
<p>The driver used was:<br>
Network UPS Tools - UPS driver controller 2.8.0<br>
Network UPS Tools - BCMXCP UPS driver 0.32 (2.8.0)</p>
<p>I simulated the fault again, by putting the UPS in bypass
and disconnecting the battery. This caused the RB alert
again. With this I then reconnected battery, restored UPS
to normal operating condition. Then used upsdrvctl to
STOP and START the driver.</p>
Generating alert condition for simulating RB:<br>
Alert type: REPLBATT<br>
.....................<br>
ups.status: ALARM OL BYPASS RB<br>
ups.test.result: Done and error<br>
<br>
Alert cleared on UPS, and alert condition with RB persisting
on NUT-SERVER:<br>
Alert type: ONLINE<br>
.................<br>
ups.status: OL RB<br>
<p>ups.test.result: Done and passed</p>
Restarting using upsdrvctl start/stop command clears RB:<br>
Alert type: COMMOK<br>
..................<br>
ups.status: OL<br>
ups.test.result: Done and passed<br>
<p>So it seems that your and my suspicions have been
verified. Where bcmxcp seems to "latch" the alarm until
driver restart or server reboot.</p>
<p>I think you are correct, in that this can cause issues in
other subsets of real-life cases. Thinking here of
automating and scripting and so forth.</p>
<p>What would you suggest at this point? Can this be
submitted as a bug?</p>
<p>Vyasa<br>
</p>
<p><br>
</p>
<p><br>
</p>
<div>On 6/30/25 14:18, Jim Klimov wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div>Hello,</div>
<div><br>
</div>
<div> You mention that you've tried restarting the
"nut-server" - I suppose you mean literally, the
service unit by such name - of the NUT data server.
Did you try restarting the unit for the NUT driver
(e.g. `systemctl restart nut-drvier@upsname` with NUT
v2.8.x and newer)?</div>
<div><br>
</div>
<div> You did not mention the driver used, but I wonder
if that driver program "latches" the RB value when it
goes bad and never updates it?.. This could make sense
when UPS battery replacement means server downtime,
but that is just a subset of real-life cases - so
generally can be just an oversight. For example,
`bcmxcp` code seems to only set
`bcmxcp_status.alarm_replace_battery=1` (oddly neither
the field nor struct is ever initialized to 0, so
might be garbage on some systems/compilers that do not
zero-out aggregate types by default).</div>
<div><br>
</div>
<div>Jim</div>
<div><br>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Mon, Jun 30, 2025
at 7:53 PM Vyasa via Nut-upsuser <<a
href="mailto:nut-upsuser@alioth-lists.debian.net"
target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">nut-upsuser@alioth-lists.debian.net</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote"
style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<p>Hello,</p>
<p>CONFIGURATION:<br>
</p>
<p>I am using a Powerware PW9120 3000i, on a network
configuration with a server and a couple of
slaves. <br>
</p>
<p>The nut-server OS is <i>Debian 12
(6.1.0-37-amd64)</i>. Nut was installed from
the Debian repo with version <i>2.8.0-7 amd64</i>,
and client has the same version.</p>
<p>UPS is connected with a standard RS232 serial
connection, and works with all standard commands
and functionality.</p>
<p>Command "<i>upscmd -l upsname</i>" provides the
following, where I have successfully used <i>test.battery.start</i>
and <i>test.system.start</i>:</p>
<p>beeper.disable - Disable the UPS beeper<br>
beeper.enable - Enable the UPS beeper<br>
beeper.mute - Temporarily mute the UPS beeper<br>
load.on - Turn on the load immediately<br>
outlet.1.load.off - Turn off the load on outlet 1
immediately<br>
outlet.1.load.on - Turn on the load on outlet 1
immediately<br>
outlet.1.shutdown.return - Turn off the outlet 1
and return when power is back<br>
outlet.2.load.off - Turn off the load on outlet 2
immediately<br>
outlet.2.load.on - Turn on the load on outlet 2
immediately<br>
outlet.2.shutdown.return - Turn off the outlet 2
and return when power is back<br>
shutdown.return - Turn off the load and return
when power is back<br>
shutdown.stayoff - Turn off the load and remain
off<br>
test.battery.start - Start a battery test<br>
test.system.start - Start a system test<br>
</p>
<p>ISSUE:</p>
<p>Every couple of years when I have to replace
batteries in the UPS, I get an issue with not
being able to clear the REPLBATT alert. That is
not until I reboot the server running NUT-SERVER.
This might seem as not a big deal, but becomes a
hassle when batteries haven't quite failed yet and
are still good after a ups battery test.</p>
<p>The UPS itself reports OK after battery
replacement or battery test, and clears alarm on
its LCD. But when I poll the UPS data using "upsc
upsname" I still see the RB or REPLBATT and this
will not clear until I reboot the server. So
without reboot the alert will then be generated
based on RBWARNTIME in upsmon.conf, which is as
per nut design.<br>
</p>
<p>So without reboot I always get the RB flag with
status:</p>
<i>Alert type: REPLBATT</i><br>
<i>............</i><br>
<i>ups.status: OL RB</i><br>
<i>ups.test.result: Done and passed</i><br>
<p>After reboot of server the alert is cleared:</p>
<i>Alert type: COMMOK<br>
............<br>
ups.status: OL<br>
ups.test.result: Done and passed</i><br>
<p>So my question becomes, why is this reboot
required and it doesn't seem to make any sense? I
can't understand why the polled data from a UPS
would change after a reboot, while on the UPS LCD
its reporting all OK? I tried restarting
NUT-SERVER to see if it would make any
difference. Also, the command test.battery.start
will clear the alarm on the UPS if battery test
good.</p>
<p>The only explanation that I have come up with is
that the persistent RB/REPLBATT is latched to this
condition and is an artifact of UPS to NUT
handshaking.<br>
</p>
<p>Any feedback would be kindly appreciated, as I
have searched and searched.</p>
<p>Thank you!<br>
</p>
Vyasa<br>
</div>
_______________________________________________<br>
Nut-upsuser mailing list<br>
<a href="mailto:Nut-upsuser@alioth-lists.debian.net"
target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">Nut-upsuser@alioth-lists.debian.net</a><br>
<a
href="https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser"
rel="noreferrer" target="_blank"
moz-do-not-send="true" class="moz-txt-link-freetext">https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser</a><br>
</blockquote>
</div>
</blockquote>
</div>
</blockquote>
</div>
</blockquote>
</body>
</html>