I've been able to get the latest Windows port installed on my Hyper-V 2012
R2 instance and start the service.
But as I'm an absolute beginner I'm not sure how to proceed further.
I've browsed the archives, but discussions here tend to assume at least an
intermediate level of understanding; thus it's still quite a bit over my
head. Your patience and slow explanations are appreciated.
I presently have four issues:
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."
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)."
3. I don't understand what's meant by "shutting down the UPS."
(e.g. upsdrvctl,
http://lists.alioth.debian.org/pipermail/nut-upsuser/2015-April/009652.html) Why
would we want to do that? It should be the other way around--the UPS stays
running while the computer shuts down--no? Please clarify.
4. What's next? I'd like to configure things to run a simple batch file
after [x] minutes of on-battery time.
Can you assist?
Here's my configuration and libUSB information:
=========================================nut.conf
MODE=standalone
ups.conf
[ups]
driver = usbhid-ups
port = auto
[upsmon]
password = passwd
upsmon master
upsmon.conf
MONITOR myups at localhost 1 upsmon passwd master
SHUTDOWNCMD "C:\\WINDOWS\\system32\\shutdown.exe -l"
POWERDOWNFLAG "C:\\killpower"
=========================================DLL version: 1.2.6.0
Driver version: 1.2.6.0
bus/device idVendor/idProduct
bus-0/\\.\libusb0-0001--0x051d-0x0003 051D/0003
- Manufacturer : American Power Conversion
- Product : Smart-UPS C 1000 FW:UPS 10.0 / ID=1005
- Serial Number: 3S1520X04472
bLength: 18
bDescriptorType: 01h
bcdUSB: 0200h
bDeviceClass: 00h
bDeviceSubClass: 00h
bDeviceProtocol: 00h
bMaxPacketSize0: 40h
idVendor: 051Dh
idProduct: 0003h
bcdDevice: 0106h
iManufacturer: 1
iProduct: 2
iSerialNumber: 3
bNumConfigurations: 1
wTotalLength: 41
bNumInterfaces: 1
bConfigurationValue: 1
iConfiguration: 0
bmAttributes: e0h
MaxPower: 1
bInterfaceNumber: 0
bAlternateSetting: 0
bNumEndpoints: 2
bInterfaceClass: 3
bInterfaceSubClass: 0
bInterfaceProtocol: 0
iInterface: 0
bEndpointAddress: 81h
bmAttributes: 03h
wMaxPacketSize: 64
bInterval: 20
bRefresh: 0
bSynchAddress: 0
bEndpointAddress: 01h
bmAttributes: 03h
wMaxPacketSize: 64
bInterval: 10
bRefresh: 0
bSynchAddress: 0
=========================================
Thanks,
Jeff Bowman
Fairbanks, Alaska
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20160908/415e002d/attachment.html>
On Thu, 8 Sep 2016, Jeff Bowman wrote:> I?ve been able to get the latest Windows port installed on my Hyper-V 2012 R2 instance and start the service. > > But as I?m an absolute beginner I?m not sure how to proceed further. I?ve browsed the archives, but discussions here tend to assume at least an > intermediate level of understanding; thus it?s still quite a bit over my head. Your patience and slow explanations are appreciated. > > 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.? > > 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).? > > 3. I don?t understand what?s meant by ?shutting down the UPS.? (e.g. upsdrvctl, > http://lists.alioth.debian.org/pipermail/nut-upsuser/2015-April/009652.html) Why would we want to do that? It should be the other way around--the UPS > stays running while the computer shuts down--no? Please clarify.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.> 4. What?s next? I?d like to configure things to run a simple batch file after [x] minutes of on-battery time.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 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. Roger
On 09/08/2016 10:46 AM, Roger Price wrote:> > 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.It would be handy if a UPS would delay returning power to attached equipment until the battery reached a minimum charge or runtime. This would in addition create hysteresis to weather the unreliable power without constant shutdowns (and disk platter spinups - for those using platters).
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-filePerfect. 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.> RogerThanks again, Jeff Bowman Fairbanks, Alaska