DSM 7.0 Another DSM7 regression: UPS

Currently reading
DSM 7.0 Another DSM7 regression: UPS

I just realised, is the option "until low battery" a new option with respect to shutting down the NAS in Standby mode?

Is this Synology's low tech workaround to shutting the NAS down but still getting it close to max run time of the UPS so there is only a small chance the power will come back on in that timeframe?

I wonder how long you actually get for the NAS to shut down - you wouldn't want it half way before the power gave out!
 
@tb123

DSM6 (this NAS is used as a UPS Server):

DSM6.png


DSM7 (this NAS is used as a UPS client):

DSM7.png


--®--
 
Last edited:
Hey, can one of you guys test something for me?

I just did the following and my assumption was that once the NAS went into Standby mode, it wouldn't recover if power was reapplied to the UPS before it's batteries were exhausted as the power was never actually removed from the NAS (restart after power failure). I have my NAS to enter Standby mode after 2 minutes.

  • 0 minutes, turn off power to UPS
  • 2 minutes, Status light started flashing (indicating shutting down)
  • at around 3 minutes something, received an email stating NAS was shut down and will be restarted once UPS is recovered. Status lights and disc lights still flashing
  • 7 minutes, turned power back on to UPS
  • 7.45 minutes, all lights went off except for Blue lights
  • after a few more minutes, NAS restarted on it's own (which surprised me!)
-- post merged: --

In other news, received this reply from Synology support regarding this issue, good news!

For the option "Shut down UPS when the system enters Standby Mode" has been removed in DSM7.

We have noticed that there have users who may need this function and our developer and product team are already under discussion on how to adjust and optimize this function. Thank you for bringing this issue to our attention.

If you need to suggest more features, you could also submit the following form to let the PM team know you ideas:
Feature Inquiry | Synology Incorporated

If there is any problem, please feel free to contact us.

Sincerely,


Technical Support Synology
 
Hopefully there has been enough articulate feedback as to why this feature is needed ... whether or not the UPS itself support a shutdown signal it is vital for the NAS to be able to come out of safe/standby mode without relying on a power loss/restore.

As for you test: which UPS do you have? I have been reading what constitutes the user manuals for my two APC models and they have different features.

APC Back-UPS BX950UI has this feature:
No-load Shutdown
If the UPS is operating on battery power and detects that the connected equipment is using less than 15 W of energy for more than 15 minutes, it will shut down to conserve energy.

When the UPS is reconnected to AC power, the UPS will automatically switch on.

Whereas the APC Back-UPS ES700 does not state this feature.

Both are pretty basic units so I'm not convinced that they support shutdown signalling, and if I have tested then I don't remember doing it. Hence why it would be useful for the NAS to monitor battery level even in safe mode.
 
As for you test: which UPS do you have? I have been reading what constitutes the user manuals for my two APC models and they have different features.

I just have a small APC Back-UPS CS 650 (It DID shut down just fine when the NAS went into Standby mode)

I don't know if it has the feature you mention (I only had it powered off for 7 minutes, it probably wouldn't make 15 tbh), however at no stage during my test did the NAS completely lose power, there were always LED's (Status and 4 x Discs) flashing. I'm wondering if it signals something over the USB when power gets reapplied? I have all my other network on the UPS and nothing else suffers from power loss while it's running on batteries or after power is restored, so assume the NAS doesn't either.
 
Last edited:
I can remember people calling for snmp UPS network management, rather than USB alone to the first NAS, back in the 2012 timeframe. At least they now appear to provide it properly some 9 years later.

I should look at setting it up as I do have a network card / web-server in my UPS but it seems ages ago that I had to concern myself with manually setting snmp configurations.

[edit:] Synology seems to only support snmp V1 - a standard from the late '80s, or V2c which reinstated the lack of security from V1. Bonkers. I thought these old standards were finally depreciated in the early '00s and were on their way out even when Synology launched its very first NAS! Funny old thing my UPS presumes snmp V3 and I don't think the protocol is backwards compatible.

[further edit:] Synology documents V1 & V2c only but on my test NAS on DSM7 you can actually select V3 during setup. Aside from the mixed-messaging this could be an improvement in DSM7 after all.
 
Last edited:
A bit of searching in DSM 7 and I find this at line 42 onwards in /usr/syno/bin/synoups
Bash:
UPSSafeShutdown=`/bin/get_key_value $SYNOUPS_CONF ups_safeshutdown`
case "${UPSSafeShutdown}" in
[Nn][Oo])
    UPSSafeShutdown=0;;
[Yy][Ee][Ss])
    UPSSafeShutdown=1;;
*)
    UPSSafeShutdown=0;;
esac

Then from line 117
Bash:
        if [ $UPSSafeShutdown -eq 0 ]; then
            echo "Waiting UPS exhausted." >> $SZF_SAFEMODE
            SYSLOG "Waiting UPS exhausted."
        else
            echo "UPS safe shutdown." >> $SZF_SAFEMODE
            SYSLOG "UPS safe shutdown."

            shutdown_retry=0
            while [ $shutdown_retry -ne 3 ]; do
                StopUps
                /usr/bin/upsdrvctl shutdown
                if [ $? -eq 0 ]; then
                    return 0
                fi
                shutdown_retry=`expr $shutdown_retry + 1`
                echo "UPS shutdown retry ... $shutdown_retry" >> $SZF_SAFEMODE
                echo "UPS shutdown retry ... $shutdown_retry" > /dev/kmsg
                # omron driver will reset usb (~30s) when command timeout
                sleep 40
            done
            echo "UPS shutdown fail." >> $SZF_SAFEMODE
            echo "UPS shutdown fail" > /dev/kmsg
        fi

Going backwards through sourced /usr/syno/bin/synoupscommon gets us to /usr/syno/etc/ups/synoups.conf which, for me has this
Bash:
Password:
ups_enabled="yes"
ups_mode="usb"
ups_safeshutdown="no"
ups_acl="<other NAS IP>|||||"

Looking in DSM 6 these parameters were in /etc/synoinfo.conf and I didn't see ups_safeshutdown in my file. But in DSM 6 the test was this... assume we can shutdown the UPS unless parameter exists and set to "no".
Bash:
UPSSafeShutdown=`/bin/get_key_value $SYNOUPS_CONF ups_safeshutdown`
case "${UPSSafeShutdown}" in
[Nn][Oo])
    UPSSafeShutdown=0;;
*)
    UPSSafeShutdown=1;;
esac

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.
Bash:
[Nn][Oo])
    UPSSafeShutdown=1;;

Any brave souls?
Brave Soul reporting :)

This is what I did on my NAS:

File: /usr/syno/bin/synoups

- Commented out line 45

- Added line 46
(could have also commented out line 42 and defined UPSSafeShutdown as 1; whatever floats your boat)

42 UPSSafeShutdown=`/bin/get_key_value $SYNOUPS_CONF ups_safeshutdown`
43 case "${UPSSafeShutdown}" in
44 [Nn][Oo])
45 # UPSSafeShutdown=0;;
46 UPSSafeShutdown=1;;
47 [Yy][Ee][Ss])
48 UPSSafeShutdown=1;;
49 *)
50 UPSSafeShutdown=0;;
51 esac

Also note that there is a mistake in /etc/ups/upssched.conf:

When you define a timeout value in the UPS configuration screen it adds a START-TIMER upssched command. The problem is a missing AT ONLINE * CANCEL-TIMER command (the only one in the file is useless because fsd is not defined as a timer).

- Commented out the useless line 116

- Added line 117 (cancel the timer and if the timer has just expired, pass the "online" argument to /usr/syno/bin/synoups)

115 AT ONLINE * EXECUTE online
116 #AT ONLINE * CANCEL-TIMER fsd
117 AT ONLINE * CANCEL-TIMER waittimeup online
118 AT LOWBATT * EXECUTE lowbatt
119 AT NOCOMM * EXECUTE nocomm
120 AT FSD * EXECUTE fsd
121 AT ONBATT * EXECUTE onbatt
122 AT ONBATT * START-TIMER waittimeup 900 <--- added by the GUI script

Below, the default behaviour with a 10 second brownout and a 5 minute timeout configured on the NAS:

The NAS log:

2021-08-28T12:13:43-04:00 SUSHI upsmsg[21331]: UPS on battery.
2021-08-28T12:13:51-04:00 SUSHI upsmsg[21469]: UPS back online, not in safe mode
2021-08-28T12:18:44-04:00 SUSHI upsmsg[22268]: UPS wait time up



SNMP UPS slave server log:

Aug 28 12:13:44 carp upsmon[894]: UPS [email protected] on battery
Aug 28 12:13:49 carp upsmon[894]: UPS [email protected] on line power
Aug 28 12:18:44 carp upsmon[894]: UPS [email protected]: forced shutdown in progress

1- The slave stays off (power never goes out, so it does not restart)

2- If you restart the server, since the NAS never cancelled the FSD, it will shutdown again.

I'll see if they fix this in the next update.

Phil
 
This "feature" is more convoluted, and seemingly deadly, than first noticed. And remains an issue with v7.0.1 RC

If you rely on the NAS as an snmp UPS server, the connected slaves will shutdown even if power comes back before the timer expires. Worse, until you restart the UPS service on the NAS, you will not be able to restart the connected slaves as they will always shutdown right after rebooting.

Reference
 
The more I see issues such as this the more laughable Synology's quest to be recognised in the enterprise or business environment becomes.

Use of a UPS with a NAS is critical with data on the fly or cached. If they make repeated mistakes or stupid policy decisions then just how can we trust them with our data?

Synology, wisely and correctly, stresses the importance of a UPS as part of the package yet handicaps or outright breaks the very tools that make this stuff work. As they use NUT for management rather than anything proprietary there is simply no excuse for their stumbles or stupidity (eg if you use any of the top UPS manufacturers you are now 'unsupported', even if you were several weeks ago).
 
Add me to this. I had done my quarterly UPS test and I have to Raspberry Pi's running as slaves, cut off mains for two minutes, restored mains and a minute later both Pi's shutdown and whenever restarted they would just shutdown again. Had to pull SD cards and disable NUT on them.
 
Last edited:
You aren't kidding, this is one dangerous situation where all slaves will just keep shutting down. What I have done since reading this thread and poking around in the config is commented out a the fsd commands to the UPS monitor that seems to be the culprit.



/usr/syno/bin/synoups line 263:

Bash:
case "$1" in
online)
        SynoUpsStateLog "synoups online"
        UPSRestart
        ;;
onbatt)
        SynoUpsStateLog "synoups onbatt"
        ONBatt
        ;;
lowbatt)
        SynoUpsStateLog "synoups lowbatt"
        UPSLowBattCheck
        UPSSafeMode $1
        ;;
nocomm)
        SynoUpsStateLog "synoups nocomm"
        UPSSafeMode $1
        ;;
fsd)
        SynoUpsStateLog "synoups fsd"
       /usr/sbin/upsmon -c fsd
        UPSSafeMode $1
        ;;
shutdownups)
        SynoUpsStateLog "synoups shutdownups"
        UPSShutdown
        ;;
status)
        SynoUpsStateLog "synoups status"
        UPSStatusGet
        ;;
waittimeup)
        SynoUpsStateLog "synoups waittimeup"
        UPSWaitTimeUp
#       /usr/sbin/upsmon -c fsd
        UPSSafeMode $1
        ;;
statelog)
        SynoUpsStateLog "synoups statelog"
        ;;
esac
 
Last edited:
Add me to this. I had done my quarterly UPS test and I have to Raspberry Pi's running as slaves, cut off mains for two minutes, restored mains and a minute later both Pi's shutdown and whenever restarted they would just shutdown again. Had to pull SD cards and disable NUT on them.
This is caused by the change they made to the timer name
You aren't kidding, this is one dangerous situation where all slaves will just keep shutting down. What I have done since reading this thread and poking around in the config is commented out a the fsd commands to the UPS monitor that seems to be the culprit.



/usr/syno/bin/synoups line 263:

Bash:
case "$1" in
online)
        SynoUpsStateLog "synoups online"
        UPSRestart
        ;;
onbatt)
        SynoUpsStateLog "synoups onbatt"
        ONBatt
        ;;
lowbatt)
        SynoUpsStateLog "synoups lowbatt"
        UPSLowBattCheck
        UPSSafeMode $1
        ;;
nocomm)
        SynoUpsStateLog "synoups nocomm"
        UPSSafeMode $1
        ;;
fsd)
        SynoUpsStateLog "synoups fsd"
       /usr/sbin/upsmon -c fsd
        UPSSafeMode $1
        ;;
shutdownups)
        SynoUpsStateLog "synoups shutdownups"
        UPSShutdown
        ;;
status)
        SynoUpsStateLog "synoups status"
        UPSStatusGet
        ;;
waittimeup)
        SynoUpsStateLog "synoups waittimeup"
        UPSWaitTimeUp
#       /usr/sbin/upsmon -c fsd
        UPSSafeMode $1
        ;;
statelog)
        SynoUpsStateLog "synoups statelog"
        ;;
esac
That will prevent your slaves from shutting down in a real power outage. The issue really is the name of the timer (waittimeup). I was previously called fsd, and was changed to waittimeup:

File: /etc/ups/upssched.conf

I commented out the line referring to the old timer name and added a new one with the proper name

Bash:
115 AT ONLINE * EXECUTE online
116 #AT ONLINE * CANCEL-TIMER fsd
117 AT ONLINE * CANCEL-TIMER waittimeup online # the line I added
118 AT LOWBATT * EXECUTE lowbatt
119 AT NOCOMM * EXECUTE nocomm
120 AT FSD * EXECUTE fsd
121 AT ONBATT * EXECUTE onbatt
122 AT ONBATT * START-TIMER waittimeup 900 #<--- added by the GUI script


Tested fine with a brownout (the timer gets cancelled and the FSD command is aborted).
Of course, if the timer expires, the slaves will shutdown properly now.

Here's a log from one of the slaves:

Sep 01 08:48:04 carp upsmon[898]: UPS [email protected] on battery
Sep 01 08:49:09 carp upsmon[898]: UPS [email protected] on line power
Sep 06 07:22:38 carp upsmon[898]: UPS [email protected] on battery
Sep 06 07:22:48 carp upsmon[898]: UPS [email protected] on line power

And the NAS log:

2021-09-01T08:48:05-04:00 SUSHI upsmsg[6252]: UPS on battery.
2021-09-01T08:49:12-04:00 SUSHI upsmsg[6531]: UPS back online, not in safe mode
2021-09-06T07:22:35-04:00 SUSHI upsmsg[29683]: UPS on battery.
2021-09-06T07:22:47-04:00 SUSHI upsmsg[29823]: UPS back online, not in safe mode


Phil
 
Thanks, yep I was aware that my edit would prevent the slaves from shutting down by not setting FSD I was gong to code my own shutdown on the slaves once they detected on battery events. Your edits will save me that work.
 
got to this forum from a good poster over on synology forum. i posted a similar help message as below. figure i shoule post here too.

the other day i had something like this issue on this thread. house had power outage and my ups's went online. power came back before they shutdown. the ds1512+ has stayed in suspend mode..i've rebooted it twice. the ds214play came back up just fine. both are running dsm 6.2.4.x. i say both, i know the ds214play is since i can access it. the ds1512+ i think is or is at a version just prior to this 6.2.4.x

i noticed today that two of my apc ups's are listed as "online shutting down". the rpi that monitors my 4 apc ups's has apcupsd running. the two synology units just happen to be plugged into one of those listed status as "online shutting down".

though the two ups's in question are up and running the ds1512+ is in suspend mode. maybe the older apcupsd scripts/configs i've had running has issues with the new DSM 6.2.4.x that is running on the ds1512+. seems likely reading through the posts here but it could be something else.

synology tech support suggested i implement this procedure:

How do I reset my Synology NAS? (For DSM 6.2.4 or above) - Synology Knowledge Center

after seeeing the apcupsd monitor status i want to check if there is another fix for this. not sure what to do now. don't want to scramble all that data on this unit attempting the incorrect fix. TIA
 
This is caused by the change they made to the timer name

That will prevent your slaves from shutting down in a real power outage. The issue really is the name of the timer (waittimeup). I was previously called fsd, and was changed to waittimeup:

File: /etc/ups/upssched.conf

I commented out the line referring to the old timer name and added a new one with the proper name

Bash:
115 AT ONLINE * EXECUTE online
116 #AT ONLINE * CANCEL-TIMER fsd
117 AT ONLINE * CANCEL-TIMER waittimeup online # the line I added
118 AT LOWBATT * EXECUTE lowbatt
119 AT NOCOMM * EXECUTE nocomm
120 AT FSD * EXECUTE fsd
121 AT ONBATT * EXECUTE onbatt
122 AT ONBATT * START-TIMER waittimeup 900 #<--- added by the GUI script


Tested fine with a brownout (the timer gets cancelled and the FSD command is aborted).
Of course, if the timer expires, the slaves will shutdown properly now.

Here's a log from one of the slaves:

Sep 01 08:48:04 carp upsmon[898]: UPS [email protected] on battery
Sep 01 08:49:09 carp upsmon[898]: UPS [email protected] on line power
Sep 06 07:22:38 carp upsmon[898]: UPS [email protected] on battery
Sep 06 07:22:48 carp upsmon[898]: UPS [email protected] on line power

And the NAS log:

2021-09-01T08:48:05-04:00 SUSHI upsmsg[6252]: UPS on battery.
2021-09-01T08:49:12-04:00 SUSHI upsmsg[6531]: UPS back online, not in safe mode
2021-09-06T07:22:35-04:00 SUSHI upsmsg[29683]: UPS on battery.
2021-09-06T07:22:47-04:00 SUSHI upsmsg[29823]: UPS back online, not in safe mode


Phil


Just wanted to give you a heads up that your changes upssched.conf worked great last night. We had three voltage lows last night for some unknown reason and each one lasted for less that 4 seconds. Looking at my logs on my slave device it was recognized each time for going on battery and then resuming. Without these changes the master would have set the FSD flag and my slaves would have gone offline.
 
after seeeing the apcupsd monitor status i want to check if there is another fix for this. not sure what to do now. don't want to scramble all that data on this unit attempting the incorrect fix.
If you make the edits suggested by @DickBlonov , then restart your primary NAS, I understand all will be fixed... until the next DSM update. Yes?
 
One can only hope that the next DSM7 update includes such a correction.

I have my main NAS on DSM6 because of these issues. Power outages are incredibly rare here but as my UPS regularly tests the battery, which includes a brief switchover, I just cannot tolerate the impact on my other NASes.
 
Last edited:
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.
 

Create an account or login to comment

You must be a member in order to leave a comment

Create account

Create an account on our community. It's easy!

Log in

Already have an account? Log in here.

Similar threads

Hello and welcome to the forum. Update for your 918 can be done by visiting the following link, and there...
Replies
1
Views
1,252
Sorry I didn't check forum often. Today I updated the DSM and S.M.A.R.T. database, the issue is gone...
Replies
141
Views
24,138
UPS's with AVR (Automatic Voltage Regulation) are worth the added expense... They'll take care of voltage...
Replies
13
Views
3,333
  • Question
So just in case anyone else gets this problem I thought I'd do an update. It turned out I was having this...
Replies
8
Views
2,287

Welcome to SynoForum.com!

SynoForum.com is an unofficial Synology forum for NAS owners and enthusiasts.

Registration is free, easy and fast!

Back
Top