[Nut-upsuser] How to get started (Windows)

[Jeff Bowman]

Thank you VERY much, Roger, for your detailed explanations. I'm going to choose to heed your warning.

> On Thu, 8 Sep 2016, Jeff Bowman wrote:
> 
> > 1. CLI error: I get an error when running ‘upsdrvctl start’: “Can't
> > claim USB device [051d:0003]: libusb0-dll:err [claim_interface] could not
> claim interface 0, win error: The requested resource is in use.”

The solution to this was easy: the conflict occurred because the service was running. Apparently NUT.exe on Windows runs all of the preparatory commands, one of which is 'upsdrvctl start.'

> > 2. Event log errors: As noted the service starts fine, but I’m getting
> > these two errors on service stop--“Error stopping upsd (2)” and “Error
> stopping upsmon (2).”

This one is still unresolved. Is there a detailed log file somewhere?

> It's assumed in the NUT world that you are running a server which is a) to be
> shut down when wall power fails for too long, and which is b) to be brought
> back into service automatically when wall power finally returns.
> 
> a) is shutting down the server using the SHUTDOWNCMD
> 
> b) is more subtle.  After, and I repeat _after_, the server has shut down,
> the UPS unit must be put into a state where is can react to the return of
> wall power, and signal the server to restart.  A UPS which is left beeping
> cannot do that.  To get the server going again it is necessary to perform a
> "delayed shutdown" of the UPS unit itself.  This might be some 30 seconds
> after the server has shut down.  Once the UPS unit is itself shutdown, it
> will react to a return of wall power by applying power supply to the server,
> and the server will, if the BIOS is set up correctly, power up, and resume
> duty.
> 
> The use of the term "shutdown" for both the server and the UPS unit is not
> the happiest choice, but we live with it.

I've decided not to seek the server restart part of b). Either I or someone else will manually turn the server on once it's determined that power has reliably resumed.

That said, is there a way to manually poll the driver for UPS/power line status? I ask because I can foresee a scenario such as this:

  - I am offsite
  - Power event occurs
  - Server sends 'delayed shutdown' signal to UPS (as described, thank you)
  - Server shuts down
  - UPS shuts down
  - Power resumes
  - I contact someone onsite
  - With me on the phone, he manually powers the server on (a ten-minute
    startup sequence occurs before the OS is fully loaded)
  - He leaves the area (he won't be able to sit there on his thumbs for the
    full startup time)
  - Power event occurs again, during the startup sequence and before NUT can
    begin monitoring

Of course the odds of all this actually occurring are slim, but I have mission-critical files that bear risk of corruption in the event of a plug-pull. I can't afford to take chances. If it's 0.001% it's 100%.

So I'd like to be able to remote in and check the status to make sure everything is OK. If not, then I can manually run my shutdown script/process and start the cycle all over again. (Note: running 'upsc ups at localhost' echoes only a blank line to the screen, as do both 'upsmon' and 'upsd.')

> There are two schools of thought for managing wall power loss.
> 
>   Optimist: Keep going as long as possible on battery and turn off the server
> when the low-battery signal is received.  No timer needed,  This is the
> simplest approach.
> 
>   Pessimist: Whenever OB is received, start timers to shut down the server
> after a short interval. Expect wall power to return and then fail again.
> Hope that the battery will recover enough between failures for the next
> shutdown.  This is for people with unreliable wall power supplies.  Using
> timers is more complicated.
>
> If you want simplicity, use the LB state as your guide, and set up your
> upsmon.conf to react to it.  ( I don't do this, so the following is
> speculative. ) In upsmon.conf set
> 
>   NOTIFYMSG  LOWBATT "Power failure - system is shutting down"
>   NOTIFYFLAG LOWBATT SYSLOG+EXEC+WALL
>   NOTIFYCMD  /path/to/your/system-shutdown-batch-file

Perfect. I'm going to prefer the Pessimist approach, but with simplicity (no NUT timers). I'll handle timers/loops/checks and other logic from within my shutdown script/process.

So to confirm my understanding:

You're stating that I'll want to do this via NOTIFYFLAG ONBATT SYSLOG+EXEC and NOTIFYCMD (no WALL in Windows), using that combination to run my script/process and skipping SHUTDOWNCMD altogether--correct?

Sounds good. Next up: how to then send the 'delayed shutdown' command to the UPS hardware itself? Does the driver automatically handle that? I'd like everything to occur shortly after the OB signal, so as to preserve battery as much as possible.

> You don't use upssched.
> 
> If you want timers, look at http://rogerprice.org/NUT.html which contains a
> fully worked example.  It's more complicated.  You have been warned.

That's quite a writeup. But you're correct--I'll pass.

> Roger

Thanks again,
Jeff Bowman
Fairbanks, Alaska