Which UPS system/device is supported best by Rockstor (NUT) to get shutdown process initiated?

I’m thinking of buying a UPS unit (best case small & cheap :smiley: ) to “overcome” the BTRFS raid 5/6 issue at sudden power loss.

Out from another thread I noted that you @phillxnet can most likely provide me with an advice.
What are the features that the UPS needs to have in order to connect it to Rockstor - so that the system knows it needs to shutdown? being connected via USB cable or LAN?

Are there any HowTo’s existing on that subject?



Rockstor simply uses NUT (Network UPS Tools) internally so your best bet is to look for a UPS that has good NUT support / compatibility. The Rockstor official docs has the UPS / NUT Setup section which in turn links to their Hardware compatibility list as does the Rockstor NUT configuration screen via the driver tooltip popup. That would be the best guide for selecting a ‘compatible’ device: ie search for “four *” or “five *” listed models in the “Support Level” Filter selection:

Edit: (added a star for this wording)
***** vendor provided protocol and hardware

There are some more pending improvements needed in our UPS support but they are predominantly around feedback on the configuration / a widget ie UPS state. As is if it switches on your are good (hopefully). The base function is there though.

Hope that helps.

N.B. I would warn though that this does not circumvent the known issues of btrfs parity raid levels (5/6) but is advisable with all systems anyway.

1 Like

@phillxnet thanks for your quick reply, I’ll find a UPS that fits.
I fully agree that the UPS will not solve BTRFS as such, but reduces some risk…

As I was not aware that NUT is already under services included,
I’ve tried to turn it on and the following error showed up? any idea?

@glenngould Yes this is by design:

“Check the service is configured correctly via it’s spanner icon.”

It will not successfully turn on unless a valid config (via spanner icon) for an attached UPS is entered.
So check that the config you entered is appropriate for the UPS you have attached. Usually it’s the driver selection or port selection that is the culprit.

From your initial message I was under the impression you did no yet have a UPS. That is a prerequisite for this service starting.

Hope that helps.

@phillxnet thx again, yes I need to buy one first but thought I give it a try to start the service :joy:

I’ve just ordered “APC Back UPS PRO USV 550VA” and hope it will work.
-> I’ll report back to the community how it worked out :wink:

@glenngould I dont’ see that exact model in the NUT Hardware compatibility list but they have a 2 * listing for a “Back-UPS Pro USB” which may or may not be the same protocol. No entries involving the “USV” bit.

**    based on fragments of publicly available protocol

Do you have reports of that device working well with NUT from elsewhere?

@glenngould Best really to stick with 4 or 5 * rating.

@phillxnet yes, I’ve seen this rating, but I’ve looked up at some of the others with more stars and looked like that they are much more expensive or on the other hand Amazon does not give lots of choices either. “USV” means “Unterbrechungsfreie Stromversorgung” in German and euqals UPS. My HP Microserver consumes ~50W so there is no need for a massive system, for sure it should work :slight_smile:

@phillxnet finally I’ve canceled my order for “APC Back UPS PRO USV 550VA” and went for “EATON ELLIPSE ECO 650 USB DIN” which should have 5* (driver “usbhid-ups”) and is slightly cheaper :joy:

@glenngould Well done. That Eaton looks like a nice little unit, also silent which is good… And the usbhid-ups is pretty much the most generic driver, plus you can just enter “auto” for the port. Let us know how you get on with it. Remember to read that UPS / NUT Setup guide prior to configuring and let us know if it falls short. Someone has submitted a NUT dump for a larger version, Ellipse ECO 1600:


so maybe once you have it you could do a similar dump for this model and submit it to the NUT people:


@phillxnet I got the UPS already and performed the follwing steps:

  • connected the USB cable
  • set NUT to “auto” and the timer to 4min
  • pressed “submit”
  • turned the service “on”
  • removed power from UPS unit
  • received email notification from the system “ups@localhost tripped on-batt timer or event filter”
  • after 4minutes the system was automatically shut down

-> it seems all is working well :joy:

Regarding reading any status information by using /usr/local/ups/bin/upsc ups@localhost ups.status (from http://networkupstools.org/docs/user-manual.chunked/ar01s06.html) does not provide any details -> file or directory does not exist
There is no “ups” folder under “local”?
I assume using the tool under Rockstor it has been installed somewhere else?

Thanks for your help again!

@glenngould Hello again and thanks for the update:

that’s great news, glad to hear it.

The directions at http://networkupstools.org are often based on a ‘from source’ install but pretty much all linux distributions package NUT and so it’s binaries will not be placed in /usr/local. Rockstor, being based on CentOS, simply uses the prepackaged NUT binaries included with CentOS which as you guessed are elsewhere. To run the command you mention you can simply omit the path, then the packaged installed binary will be called:

upsc ups@localhost ups.status

And given yours is a standalone config (locally connected UPS) you can omit the “@localhost”:

upsc ups ups.status

or better still you can get all the info via:

upsc ups

Do you fancy copying into the thread the output of that last command (assuming it works that is)?
Note that if you precede and follow the command output paste with ‘’’ on a line of it’s own we get better formatting.

As an aside for some more use you could make of this UPS, you state that your Rockstor machine only uses 50W and given you have selected a short timed shutdown option and your UPS can do a fair bit more, capacity wise, you could consider running your network equipment on it (light additional load) plus an additional machine, ie a low power desktop.

The Brochure:
states a 9 minute battery run-time on 50% load so means you could have another (400W * 0.5) - 50W = 150W (given negligible network equipment power draw) left over to battery backup another machine. Or if you were to fly closer to the edge with 6 minutes of battery run-time on 70% load (400W * 0.7) - 50W = 230W additional load. Given the 650 model is rated at 650VA and 400W so the overhead would depend on the power factor of the attached devices.

All additional risk but their may be some facility there you didn’t realise as given both the Rockstor machine and the network are on the UPS, it is possible for the NUT in Rockstor (if configured in netserver rather than standalone mode) could inform other machines over the network (via NUT client software installed on those machines) to shut themselves down cleanly also: the client NUT software on the example other machine would be configured in netclient mode and use the credentials you establish in the netserver NUT config in Rockstor. It’s quite a nice facility but does of course depend on your Rockstor machine being on when ever the co-dependant machines are on.

Just a thought, and if not (better idea as less risk) then you could always use NUT netserver mode to be able to remotely monitor the info those commands above returned via your desktop and a graphical NUT monitor program. I cover this use in the “Some shiny” section of my “Why NUT” article I did as a Rockstor blog post.

Hope that helps.


@phillxnet thanks again for your help…here is the output I get:

[root@rockstor ~]# upsc ups
battery.charge: 100
battery.charge.low: 20
battery.runtime: 2156
battery.type: PbAc
device.mfr: EATON
device.model: Ellipse ECO 650
device.serial: 000000000
device.type: ups
driver.name: usbhid-ups
driver.parameter.pollfreq: 30
driver.parameter.pollinterval: 2
driver.parameter.port: auto
driver.version: 2.7.2
driver.version.data: MGE HID 1.33
driver.version.internal: 0.38
input.transfer.high: 264
input.transfer.low: 184
outlet.1.desc: PowerShare Outlet 1
outlet.1.id: 2
outlet.1.status: on
outlet.1.switchable: no
outlet.2.desc: PowerShare Outlet 2
outlet.2.id: 3
outlet.2.status: on
outlet.2.switchable: no
outlet.desc: Main Outlet
outlet.id: 1
outlet.power: 25
outlet.switchable: no
output.frequency.nominal: 50
output.voltage: 230.0
output.voltage.nominal: 230
ups.beeper.status: enabled
ups.delay.shutdown: 20
ups.delay.start: 30
ups.firmware: 02
ups.load: 9
ups.mfr: EATON
ups.model: Ellipse ECO 650
ups.power.nominal: 650
ups.productid: ffff
ups.serial: 000000000
ups.status: OL CHRG
ups.timer.shutdown: 0
ups.timer.start: 0
ups.vendorid: 0463

I agree with you that 4min is on the safe side, I can change, but on the other hand I had no power blackout since I’ve moved into my house >2 years -> very stable supply, the UPS unit will have an easy job :slight_smile:

1 Like

Hello all,

I did some quick testing of NUT on rockstor 4.0.4. The UPS is the cheapest box on local store - Eaton 5E 650i.

  1. The shutdown on battery drain is working fine. It is my preffered way.

  2. Timered shutdown is not working, even with uncommented lines in /opt/rockstor/conf/upssched.conf file. Logs show error:

upssched[16749]: Failed to connect to parent and failed to create parent: No such file or directory

This is probably caused by wrong path, where PIPEFN and LOCKFN points to nonexist directory.

Works with:
PIPEFN /var/lib/ups/upssched.pipe
LOCKFN /var/lib/ups/upssched.lock

  1. The beeping when UPS in on battery is very annonying, can be disabled/enabled with commands:

upscmd -u monuser -p password ups@localhost beeper.disable
upscmd -u monuser -p password ups@localhost beeper.enable

But it needs a little modification of monuser in upsd.users:

upsmon master
password = password
actions = SET
instcmds = ALL

It will be very nice to have checkbox to enable/disable beeping in web UI.

  1. The documentation of NUT project, manual pages and config examples uses password without doublequotes, while rocstore sets pasword as “password”. It is a little confusing for me.

If anyone is interested nf config UPS on OpenSuse, there is good reading:

Thanks for your work and regards


@kri164 Thanks for an excellent report.

That’s a nice find and yes It looks like failed to test that capability in our “Build on openSUSE” variant. Not a show stopper but would be good to have this fixed. Could you create a GitHub issue with your findings on this. That way once someone gets around to fixing this, as it did work in our pending legacy status CentOS variant, we can correctly attribute the bug’s report to yourself. No worries otherwise but would help with attribution.

This may not be available across the board. Not all command work on all UPS models/drivers. But agreed this would be a nice feature. But as you state, it also requires enhanced privelages for the monuser. But we could always indicate that in the Web-UI. Feel free to create another GitHub feature request GitHub issue for this one.

NUT configuration is a bit of a nightmare and has a variety of valid formats for all sorts of things. I say if our current implementation works for this setting we try not to ‘fix’ it.

Great, much appreciated. Should be a good resource for who ever ends up taking a look at this issue.

Thanks for an excellent test report. Much appreciated.


I was experiencing this same problem. Changing the entries to /var/lib/ups fixed it. @kri164, I thank you for this post and for the link to rogerprice.org. It looks like there’s a patch in git already so I’m not opening a new issue.

The UPS that I’m monitoring is attached to a Raspberry Pi running nut in netserver mode. Rockstor is connected to a UPS with no USB port, so I’ve set it up to shut down if the Pi-attached UPS is on battery for 5 minutes. 99% of my power failures are momentary and if they go longer, they tend to go a couple of hours so this 5 minute delay should work well.

Again, thank you for this post as I’ve been trying to get this bit working for much of this week.


@wdc thanks for confirming @kri164 excellent findings.

This one almost fell through the cracks. I’m afraid I failed to chase up the original report and create the associated issue myself. And consequently this was temporarily miss-placed.

I have now created the following belated issue:

and assigned it to our First 4 Stable (ISO) milestone here:

Thanks again to @kri164 and @wdc for the original report and the confirmation/prompt. The fix should be in 4.1.0-0 to be release soon hopefully.

Hope that helps.