Sweet! @Lev / @rawat - when/if either of you have a moment, it’d be good to get some additional validations.
fyi - it also seems to work without the sleep:
but, as an extra sanity check, not without the command enabled in init/shutdown scripts…
Try it a few times 
I added the sleep with the other method after noticing it would work about 60% of the time. Another good test is to try a normal shutdown of TrueNAS and make sure the UPS does not power off.
-doing a normal shut down does not turn off the ups, as you would expect (since /etc/killpower isn’t there)
- from the tests I did so far(about 5-10 each way - there’s a limit to how often I want to reboot this device as my home automation runs on it), it always turned off when calling nutshutdown via init/shutdownscript, even without the sleep, except for once, and never when not calling nutshutdown via init/shutdownscript–> this would indicate it is not even being called in the normal shutdown sequence… It certainly doesn’t hurt to have the sleep in place
If it would be “just” the sleep it should be turning off in xx% of the cases even when not manually calling nutshutdown…
Shame there seems to be no way to modify nutshutdown with the sleep inside it (and disabling the extra call to nutshutdown via init/shutdownscript), to see if it makes a difference or not that way…
I’ll try to submit it as “feedback” via truenas
2 Likes
Hopefully this thread gives them enough information to look into this more deeply. Let us know the jira number. I’ll watch it and try to help out if I can.
If I had a spare UPS lying around, I would next setup NUT on a vanilla instance of Debian stable and see if the same challenges are observed. As far as I understand, that’s the base of TrueNAS Scale. It’s possible still the issue is upstream of TrueNAS, but I doubt it at this point.
1 Like
submitted it via the gui so it should also have a screenshot of the ups config and a debug report. Tried to emphasise there is more people having the issue, and that the (ups) hardware is not immediately related…
3 Likes
the two commands working for me too :
[ -f /etc/killpower ] && { /bin/sleep 10; /lib/nut/usbhid-ups -a UPSNAME -k; }
AND
/bin/sleep 10 && /usr/lib/systemd/system-shutdown/nutshutdown
My ups is a eaton ellipse pro 650.
many thank’s for your synthesis @rymandle05
Happy new year in advance to all 
edit : When i shutdown manually truenas scale, the ups don’t stop, it’s perfect !
1 Like
Haven’t tried any of the workarounds yet but just to chime in on the issue, my APC UPS is not Powering Off after the system has shutdown itself either, despite the Power Off flag being set. Glad I found this thread because the issue seems to affect a lot of people and a variety of UPS vendors.
1 Like
EDIT: command below to try has been updated - the first one wasn’t the one they asked for (the jira post was changed)
In the ticket I made, they’ve now asked me to set while true; do if [ -f /etc/killpower ]; then upsdrvctl shutdown; break; fi; sleep 1; done
as shutdown command. Haven’t been able to check that yet, but people here having the problem may want to test that as well…
1 Like
I’m not sure I understand the need for the while true infinite loop in the command. I guess that’s better than static sleep? I gave it a try nonetheless. Running upsmon -c fsd works as expected the first time with TrueNAS shutting down and then the UPS powering off shortly after. However, subsequent tries were not always successful. The other problem I’m seeing is when you do a normal shutdown where there is no /etc/killpower file created. This command just loops until the timeout value is reached on the shutdown.
Removing the while true stuff and adding sleep 1 in front upsdrvctl shutdown seems to correct all of this.
if [ -f /etc/killpower ]; then sleep 1 && upsdrvctl shutdown; fi; sleep 1
EDIT: I spent some time thinking this over and decided to give an until loop a try until the shutdown command is successful. This is what I came up with.
if [ -f /etc/killpower ]; then until upsdrvctl shutdown; do sleep 1; done; fi
Truenas version 24.10.2
UPS - apc BX1500G
I ran into the same issue of the ups not shutting down during power failure test.
As a work around the following works.
/usr/bin/killall usbhid-ups && /lib/nut/usbhid-ups -a ups -k && /usr/sbin/shutdown now in the shutdown command.
This all kicks in after the shutdown timer interval (currently set at 60 for testing). The above command fires, then TN starts the shutdown process. The ups continues running for ~75s which is more than enough for a proper shutdown of a simple nas.
After 75s have elapsed, the UPS itself then powers off. Upon power restoration UPS turns back on.
This UPS is a rather old model, so there may be some issues there. I suppose this is similar to the work around in post 47 where the usbhid-ups driver is reloaded?
The command in post 47 doesn’t work for me, resulting in the following;
root@truenas[~]# /lib/nut/usbhid-ups -a ups -k
Network UPS Tools - Generic HID driver 0.47 (2.8.0)
USB communication driver (libusb 1.0) 0.43
Can't claim USB device [051d:0002]@0/0: Entity not found
In testing, my command above seems to be working consistently, each and every time.
Do folks have issues with ups shutdown with newer models?
1 Like
My UPS was a brand new CyperPower unit. Just looking at the models people have referenced, I don’t think is an old vs new or a particular brand issue. I’m guessing it’s either TrueNAS implementation of NUT or a bug in NUT itself. It looks like the maintainers of NUT did a lot changes in the space with more recent versions.
I’ve been meaning check out 25.04RC to see if the problem is still present. The Jira ticket for this issue was moved out to be fixed in 25.10, but it’s possible the upstream Debian repo adopted a new version.
I ended up suggesting this revision of the shutdown command to TrueNAS team via Jira after trying some of their other suggestions:
if [ -f /etc/killpower ]; then until upsdrvctl shutdown; do sleep 1; done; fi
Is this an endless loop that runs until /etc/killpower exists, executing upsdrvctl shutdown every second?
Is this the alternate shutdown command in the ups config?
Should I be able to simulate /lib/nut/usbhid-ups -a ups -k via command line? That doesn’t seem to work, coming back with the Can't claim USB device [051d:0002]@0/0: Entity not found error.
Yep, the command itself is an endless loop but only when the killpower file is present. The shutdown command has a timeout value so then it becomes an endless loop until the shutdown command timeout is reached (i.e. 60 seconds). When I tested this a few months back, it was working consistently and would be successfully after a few sleeps.
You should be able to simulate as you said but it’s not working. If, I remember correctly, that error was fixed in NUT a few versions later. Unfortunately, with 24.10, the upstream Debian repo’s hadn’t adopted those updated packages yet.
I don’t see prebuilt 2.8.2 package for debian. How does one get it?
Ultimately, if I can’t get a working version, i’ll stick with the command line above (post 71) which seems to work.
Unfortunately, it’s not really an option with TrueNAS as an out of the box appliance style operating system. We need to wait for Debian adopt it and then IX Systems to adopt from them or for IX systems to decide its worth while to install the newer version 2.8.2 version themselves. That is unless you are willing to venture into unsupported terrority and enable Developer Mode to compile or otherwise install it yourself.
I just checked 25.04-RC.1 and it looks like the installed version of NUT is still 2.8.0. I guess 25.10 is our next opportunity to get this addressed somehow someway.
^^Quite surprising this has been an ongoing issue for so long. I tested nut in pfsense (freebsd based). It had v2.8.2_4. I was able to execute usbhid-ups -a ups -k successfully in console. Ultimately, apcupsd was easier to configure via the gui - I was too impatient to figure out NUT.
It’s preached that a nas should always be attached to some sort of ups for safe shutdown!@# I’m glad we have work arounds for TN, but this should be a higher priority. Unless, the issue is with the usbhid-ups driver and not with other drivers used in larger nas deployments. /rant off
2 Likes
My Eaton UPS 2 nights ago did shut my EE machine down, but it also did not power off. Prior to EE, i.e. Dragonfish, I had tested the process and it did used to shut down. FWIW,
This worked perfectly for mine, Thanks!!
CP1350PFCLCDa version of cyberpower ups.
Glad this worked for you. I ran into another issue with that apc. UPS got powered off (but not completely), but due to firmware bug would go into a weird loop if power was restored less than 30s after this event.
This has a good write up of the issue. Screen shot below summarizes the issue well. In my use case, I decided to not power off the ups. If there’s an extended outage (very rare), then nas shuts down, and ups remains on battery until depleted. It will require manual intervention to turn the nas back on if power is restored before battery fully gone.
I haven’t bought an apc unit in ages, but had this one on hand with fresher batteries. Shame not to put it to use.