Skip to content
Oznog

5.13 · power and environment · after redaction

Real outages and planned outages need different UPS commands

date
20260913
what happened
Rehearsing the power-return sequence found that the one command NUT exposes for cut-and-restart is accepted by the UPS only while it is genuinely on battery; sent with mains present it is refused. The command that looks right for a planned stop turns out to be an eight-second reboot on this firmware, and the one that does stop the unit under mains does not restart itself when AC returns. A self-test during the rehearsal also logged a battery cartridge as not installed, then installed, ten seconds apart.
what it cost
About ninety minutes of a planned, supervised rehearsal across four deliberate power-pull cycles, plus a moment of uncertainty over whether a real battery had failed.
what changed
The design now stops the fleet early on a timer and leaves the UPS units on and idle through a planned outage, letting the real power loss trigger the same unattended on-battery sequence a genuine outage would use. Every scheduled outage is therefore also a live drill of the unattended path. The suspect cartridge's seating was flagged for a physical check.
the check now
The rehearsal's own read-back, cycle by cycle: when output cut, when it returned, and whether a pending command survives mains returning mid-delay. It does, the cut still happens, and the fleet reboots as a unit, which was judged the safe outcome.

Getting a fleet to come back on its own requires the UPS to cut its own output and restart it when mains returns, so that the return is a real AC loss and return event the BIOS has something to react to. NUT exposes one command for this, shutdown.return. Rehearsing it on an unloaded unit, with the fleet still up, turned up something a reading of the documentation does not show. The UPS accepts that command only while it is actually running on battery. Sent with mains present, which is the planned-maintenance case, it is simply refused.

The two obvious substitutes both fail differently. The outlet-group command that looks like a persistent shutdown is, on this firmware, an eight-second reboot. The command that does stop output with mains present does not restart itself when AC is lost and later returns; it needs an explicit follow-up sent by something that is, by definition, not powered yet.

Rather than write a separate planned-outage branch that would never be exercised for real, Node0 restructured the planned case to stop the fleet early on a timer and simply wait for the real power loss to fire the unattended sequence. Every scheduled outage is now a live drill of the path that matters.

The generalisable finding is this. Superficially similar “turn this off” commands can differ not just in effect but in which starting condition they will accept at all. That only shows up by testing each condition: mains present, mains absent, mains returning mid-command, rather than by trusting a command’s name. The smaller finding is worth having in your head too. Every output return here runs a battery self-test, and a self-test can look alarming; check the unit’s service history before treating a log line as a new hardware failure.

Source: node0 lessons v0.1, lesson 5.13. Sanitized: checklist v0.1, 20260921; unit identifiers; voice pass 20260921. Part of oznog.com/node0.