DSM 7.0 Another DSM7 regression: UPS

[Robbie]

Even with a single NAS, safely shutting down with power to spare is more attractive to me than running the UPS low or flat. In this condition, once the power returns and the NAS powers on, you are left with a UPS with very low power and many hours still to recharge - leaving things vulnerable for a potential subsequent or multiple false grid restarts.

Commanding a UPS to shutdown once the sensitive NAS(es) will stop other equipment on the UPS from draining unnecessary power (if all clients are down on a switch why power the switch? if devices use PoE from a switch but have nothing to do in a power outage then why power them from the UPS battery post NAS shutdown?).

 

[DickBlonov]

Very new to UPS setup in general. I have a DS918+ on DSM7.0. I've read this thread multiple times to understand what the concerns are with the users here and believe the main concern is that Syno removed the ability to shutdown the UPS (except for Omron) plus they changed some timer names. The ability to shut down the UPS so that slaves can be rebooted upon power return seems to be the main problem related to this concern.

Here is what I see happening on my setup:

From Master perspective:

DS918+ will receive notice from UPS that it is on battery. Nothing else happens except configured notifications go out. The DS918+ remains running normally.

When the UPS battery reaches LOW, the DS918+ goes into Safe/Standby mode (shutting down some services, unmounting RAID shares, etc.), but it does not shut itself off. It remains in Safe/Standby mode until power returns.

If power returns before batteries die, about 60 seconds later, the DS918+ will reboot automatically and come back up to normal operation.

If power returns after batteries die (DS918+ would have died too at this point), the DS918+ will boot up normally.

If this were a standalone unit (no slaves), I do not see any issues with this behavior except for the users that want to shut down their UPS early to save battery.

From a Slave perspective:

I do see issues here......(but still learning all the NUT commands/settings)

On my slave, it gets the "on battery" message but still runs normally.
On my slave, once the "low battery" status is reached on the master, the slave will power off.

The slave will remain off until power goes completely off and then returns ("Always On" in BIOS). If power is restored before the battery dies, the slave will never come back on.

My only issue (as far as I know) is the UPS battery must completely die so the power is removed from the slave power supply so that it will boot up once power comes back. If power returns while on battery, the slave never gets rebooted.

Following this thread while learning more about NUT.

This is what I did to "/usr/syno/bin/synoups" (force UPSSafeShutdown, comment out lines that rely on the GUI configuration for UPS shutdown. I have an APC NS1050 UPS; works perfectly fine as it did on DSM 6).

 37     echo "UPS is not enable."
 38     exit
 39     ;;
 40 esac
 41 #This is to bypass the GUI setting for a non Omron UPS
 42 UPSSafeShutdown=1
 43 : '
 44 UPSSafeShutdown=`/bin/get_key_value $SYNOUPS_CONF ups_safeshutdown`
 45 case "${UPSSafeShutdown}" in
 46 [Nn][Oo])
 47 #   UPSSafeShutdown=0;;
 48     UPSSafeShutdown=1;;
 49 [Yy][Ee][Ss])
 50     UPSSafeShutdown=1;;
 51 *)
 52     UPSSafeShutdown=0;;
 53 esac
 54 '
# End of bypass patch

Phil

 

[Telos]

This is what I did to "/usr/syno/bin/synoups"

Thanks for sharing...

 

[fredbert]

So we have ups_safeshutdown in both files. And if I set it to "yes" in synoups.conf this does not survive the UPS feature being switched off/on in Control Panel. No idea of other times it would poll the UPS and determine it must be "no". So the script seems the best place to place a hack.

[Nn][Oo])
    UPSSafeShutdown=1;;

Any brave souls?

So we have a brave soul Glad to hear it works. Can't remember if I applied it in the end or not.

This is what I did to "/usr/syno/bin/synoups" (force UPSSafeShutdown, comment out lines that rely on the GUI configuration for UPS shutdown. I have an APC NS1050 UPS; works perfectly fine as it did on DSM 6).

 37     echo "UPS is not enable."
 38     exit
 39     ;;
 40 esac
 41 #This is to bypass the GUI setting for a non Omron UPS
 42 UPSSafeShutdown=1
 43 : '
 44 UPSSafeShutdown=`/bin/get_key_value $SYNOUPS_CONF ups_safeshutdown`
 45 case "${UPSSafeShutdown}" in
 46 [Nn][Oo])
 47 #   UPSSafeShutdown=0;;
 48     UPSSafeShutdown=1;;
 49 [Yy][Ee][Ss])
 50     UPSSafeShutdown=1;;
 51 *)
 52     UPSSafeShutdown=0;;
 53 esac
 54 '
# End of bypass patch

 

[jvkpilot]

Even with a single NAS, safely shutting down with power to spare is more attractive to me than running the UPS low or flat. In this condition, once the power returns and the NAS powers on, you are left with a UPS with very low power and many hours still to recharge - leaving things vulnerable for a potential subsequent or multiple false grid restarts.

Commanding a UPS to shutdown once the sensitive NAS(es) will stop other equipment on the UPS from draining unnecessary power (if all clients are down on a switch why power the switch? if devices use PoE from a switch but have nothing to do in a power outage then why power them from the UPS battery post NAS shutdown?).

Good point. I didn't really consider saving battery life important at first but now I'm starting to see the justification. Thanks.
[automerge]1633535565[/automerge]

This is what I did to "/usr/syno/bin/synoups" (force UPSSafeShutdown, comment out lines that rely on the GUI configuration for UPS shutdown. I have an APC NS1050 UPS; works perfectly fine as it did on DSM 6).

 37     echo "UPS is not enable."
 38     exit
 39     ;;
 40 esac
 41 #This is to bypass the GUI setting for a non Omron UPS
 42 UPSSafeShutdown=1
 43 : '
 44 UPSSafeShutdown=`/bin/get_key_value $SYNOUPS_CONF ups_safeshutdown`
 45 case "${UPSSafeShutdown}" in
 46 [Nn][Oo])
 47 #   UPSSafeShutdown=0;;
 48     UPSSafeShutdown=1;;
 49 [Yy][Ee][Ss])
 50     UPSSafeShutdown=1;;
 51 *)
 52     UPSSafeShutdown=0;;
 53 esac
 54 '
# End of bypass patch

Phil

I'm going to implement these suggestions and see how it goes. Thanks.

 

[DickBlonov]

Good point. I didn't really consider saving battery life important at first but now I'm starting to see the justification. Thanks.
[automerge]1633535565[/automerge]

I'm going to implement these suggestions and see how it goes. Thanks.

FYI. "/etc/ups/upssched.conf" is copied from "/etc.defaults/ups/upssched.conf" when you enable ups support from the GUI. So unless you make the change in /etc.defaults/ups/upssched.conf, disabling and re-enabling ups support will overwrite your changes to "/etc/ups/upssched.conf". I modifed both. As far as I know, /usr/syno/bin/synoups is left unchanged by the GUI.

Phil

 

[jvkpilot]

FYI. "/etc/ups/upssched.conf" is copied from "/etc.defaults/ups/upssched.conf" when you enable ups support from the GUI. So unless you make the change in /etc.defaults/ups/upssched.conf, disabling and re-enabling ups support will overwrite your changes to "/etc/ups/upssched.conf". I modifed both. As far as I know, /usr/syno/bin/synoups is left unchanged by the GUI.

Phil

Thanks. I'll go update the etc.defaults file.

I made all the recommended tweaks and did a full test and it worked perfectly. At low battery, Master (Syno) goes to Standby, Slave shuts down, then Master shuts down UPS. When I add power everything boots back up successfully. Thanks for all the help in this forum.

 

[Telos]

I made all the recommended tweaks and did a full test and it worked perfectly.

Any chance that you would post a copy of the edited files

 

[jvkpilot]

Any chance that you would post a copy of the edited files

Here are the portions of the 2 files I edited per this thread. (I also edited the /etc.defaults/ups/upssched.conf to be the same as /etc/ups/upssched.conf):

/etc/ups/upssched.conf

AT ONLINE * EXECUTE online
#AT ONLINE * CANCEL-TIMER fsd # remarked out for testing syno/ups fix
AT ONLINE * CANCEL-TIMER waittimeup online # added for testing syno/ups fix
AT LOWBATT * EXECUTE lowbatt
AT NOCOMM * EXECUTE nocomm
AT FSD * EXECUTE fsd
ATONBATT * EXECUTE onbatt
AT ONBATT * START-TIMER waittimeup 600 # chose 10 minutes in GUI

/usr/syno/bin/synoups

#This is to bypass the GUI settings for a non-Omron UPS for syno/ups fix
#
UPSSafeShutdown=`/bin/get_key_value $SYNOUPS_CONF ups_safeshutdown`
case "${UPSSafeShutdown}" in
[Nn][Oo])
# UPSSafeShutdown=0;; # remarked this line out for syno/ups fix
UPSSafeShutdown=1;; # added this line for syno/ups fix
[Yy][Ee][Ss])
UPSSafeShutdown=1;;
*)
UPSSafeShutdown=0;;
esac
#
# End of bypass tweak for syno/ups fix

 

[Telos]

Thank you. I'm sure this will help many others.

 

[cinergi]

I just found this thread and have implemented the suggested changes. All seems to be working fine; thanks to @DickBlonov, @jvkpilot and others!

One question. If the waittimeup timer is triggered, will a UPS shutdown command always follow in order to reboot the slaves, even if the power is restored in the meantime? I hope so, because otherwise the slaves could be shut down but not rebooted, requiring manual intervention to bring them back up.

Thanks!

 

[DickBlonov]

One question. If the waittimeup timer is triggered, will a UPS shutdown command always follow in order to reboot the slaves, even if the power is restored in the meantime?

Thanks!

When the timer expires, the /usr/syno/bin/synoups script executes "upsmon -c fsd", effectively shutting down the UPS (even if the power is on). The UPS will drop the load, and come back on line. This is one command you can use to test your setup without having to pull the plug.

Phil

 

[cinergi]

When the timer expires, the /usr/syno/bin/synoups script executes "upsmon -c fsd", effectively shutting down the UPS (even if the power is on). The UPS will drop the load, and come back on line. This is one command you can use to test your setup without having to pull the plug.

Phil

Thanks! This seems to work.

 

[jvkpilot]

I recently upgraded to DSM 7.0.1-42218 and it removed the tweaks to the 2 files (/etc/ups/upssched.conf & /usr/syno/bin/synoups). I have not fixed the files yet as I want to test first (assuming it will fail), then fix the files and test again.

 

[jvkpilot]

I recently upgraded to DSM 7.0.1-42218 and it removed the tweaks to the 2 files (/etc/ups/upssched.conf & /usr/syno/bin/synoups). I have not fixed the files yet as I want to test first (assuming it will fail), then fix the files and test again.

Prior to upgrading DSM to 7.0.1-42218, I had also tweaked the file upssched.conf in the /etc.defaults/ups folder to match the same file in /etc/ups folder.

After upgrading to DSM 7.0.1-42218, all 3 files were overwritten, which removed all the tweaks.

Using the freshly overwritten files with no tweaks, I tested pulling the power with DSM 7.0.1-42218 and the slave powered down after the waittimeup and the NAS went to standby mode. Nothing else happened. I then plugged power back in and the NAS rebooted and came back up online. The UPS never shutdown which caused the slave to never power back up.

I then tweaked all the files as per the above posts and tested again by pulling power. This time everything behaved as it should. The NAS went to standby, powered the slave off, and then shut down the UPS. When I plugged power back in master and slave came back up fine.

NOTE: The "upsmon -c fsd" does not work correctly, even with tweaked files. It will shut down the slave but nothing else happens. If the slave is powered back up, it will shut back down due to the existence of the /etc/killpower, I suspect. If I reboot the NAS first, which resets everything, I can then power up the slave fine.

 

[DickBlonov]

NOTE: The "upsmon -c fsd" does not work correctly, even with tweaked files. It will shut down the slave but nothing else happens. If the slave is powered back up, it will shut back down due to the existence of the /etc/killpower, I suspect. If I reboot the NAS first, which resets everything, I can then power up the slave fine.

You might want to try "/usr/syno/bin/synoups fsd".

fsd)
    SynoUpsStateLog "synoups fsd"
    /usr/sbin/upsmon -c fsd
    UPSSafeMode $1
    ;;

Phil

 

[Telos]

I then tweaked all the files as per the above posts and tested again by pulling power. This time everything behaved as it should. The NAS went to standby, powered the slave off, and then shut down the UPS. When I plugged power back in master and slave came back up fine.

NOTE: The "upsmon -c fsd" does not work correctly, even with tweaked files. I

Color me simple-minded, but I am confused. You said that when you tweaked the files, and pulled the power,

everything behaved as it should.

Then you added that

"upsmon -c fsd" does not work correctly, even with tweaked files.

Do the tweaked files work or not?

 

[Robbie]

Prior to upgrading DSM to 7.0.1-42218, I had also tweaked the file upssched.conf in the /etc.defaults/ups folder to match the same file in /etc/ups folder.

After upgrading to DSM 7.0.1-42218, all 3 files were overwritten, which removed all the tweaks.

After installing DSM 7.0.1-42218 the GUI options appeared to return to DSM 6 levels of functionality - a full about-face from Synology?

DSM 7.0.1-42218 UPS GUI on 2 of my NASes:

So no cautions or warnings about using regular UPS brands now and, apart from layout, the DSM7 GUI is indistinguishable from that of DSM6. I have yet to test all the features but those I have do work perfectly well.

️

 

[Rusty]

I can confirm the dropdown, but my UPS server is still my main RS unit on dsm6, so not something I can test without pulling the production down.

 

[Robbie]

@Rusty I have a similar setup to you but I now intend to move my main NAS over to DSM7 in the weeks to come, now that full UPS support is back and directly supported by Synology.

This has to an increasingly rare example of Synology undoing all of one of its more unwelcome changes and restoring lost features. This has to be welcomed, should it not?