DSM 7.0 Another DSM7 regression: UPS

Currently reading
DSM 7.0 Another DSM7 regression: UPS

4,146
1,427
NAS
DS4l8play, DS202j, DS3623xs+, DSM 8.025847-𝘣𝘦𝘵𝘢
DSM7 has revealed another regression... The "Shut down UPS when the system enters Standby Mode" is now only active with Omron UPS.

Version 6
NMp448N.png


Version 7
nhNhMDp.png


DSM7 proves itself to be a true clusterfr%#*d more and more with each passing day
 
Yikes.

I have 2x DSM7 running as Synology UPS clients and nothing has changed for them, with complete data exchange and settings available with my Eaton UPS. The UPS client service is on my prime NAS which is still on DSM6.

So it looks like the the full level of client support is still included on DSM7, but they have neutered standalone mode / USB and possibly UPS Server mode too (clearly I am not minded to check the latter)!

There is nothing different about Syno UPS support as it used standard protocols so why would they pull support from the major UPS manufacturers such as APC, Eaton etc?

:oops:
 
Here's the response...
After checking internally with our developer, the "Shut down UPS when the system enters Standby Mode" feature is removed in DSM 7.0 for the majority of UPS because not every UPS can shut down properly even with the option checked.

Due to the fact that most UPS models in our compatibility list are actually recommended by UPS vendors, we cannot ensure what models actually support the feature.

This is why the feature in DSM 7.0, and we will continue collecting user feedback for further evalaution.

It makes some sense and maybe we thought we were more protected than we actually were? However, I did reply outlining the issue as I see and the mechanism that I really want to see implemented (if possible):
The problem now is how to restart the NAS if the UPS never gets to zero battery? The NAS, I think, only restarts when it detects that power is restored. Where the outages are long enough to issue NAS shutdown or safe mode then the UPS is less likely to then get to a point where a total power loss will be experienced by the NAS power supply.

What I'm thinking is that the NAS could have a mode where most functions are dormant (thus protecting RAID state) but a low level polling of UPS battery status (is it increasing over X time... indicates external power has returned) could then bring the NAS back to normal operation at a safe point (e.g. enough power to effect a safe shut down again).
 
Last edited:
It is a bonkers response. If the UPS fails to respond to the standard shutdown commands then it is an issue for the UPS vendors. Under the hood Synology is just using the normal UPS protocols and even in DSM7.0 the Synology NAS UPS clients of the Synology NAS UPS server still work normally with standard UPS commands.

I shutdown the UPS after all NASes have either shutdown or entered 'safe mode'. This is to preserve battery power in case of power being restored and subsequently lost again before the batteries have had any time to recharge. It also gives me an option to restart the UPS on battery reserve alone should there be a suitable reason to do. Shutting down the UPS when safe to do so also has the happy side effect of not deep-cycling the batteries.

All these other considerations rely on UPS firmware support and only require standard safe mode and shutdown commands from the NAS hosting the UPS or UPS server role in the case of multiple NASes.

I wonder if they could be scripted instead...

Another thought that occurs is that Syno CMS also relies on these commands to shutdown and restart managed NASes. Have they killed that functionality too?
 
Last edited:
WTaF? That’s ridiculous! How the hell can I turn my NAS back on if I’m away from home? It renders all the remote access possibilities, including VPN, completely useless.

I’ve logged a support ticket, this is freaking rediculous.
-- post merged: --

Remote access power sockets?
remote access via the VPN on the NAS?
Oh, wait, its turned off…
 
Ok, I formally call BS on the statements from Synology.

I picked a DSM 7.0 NAS to see if Synology still uses and embeds Network UPS Tools (NUT) for full Syno UPS control:

Code:
Last login: Sat Aug  7 09:07:04 on ttys000
rob@Robs-MBP ~ % ssh rob@dragon
rob@dragon's password:

Synology strongly advises you not to run commands as the root user, who has
the highest privileges on the system. Doing so may cause major damages
to the system. Please note that if you choose to proceed, all consequences are
at your own risk.

Rob@Dragon:/$ sudo cat /usr/syno/etc/ups/ups.conf

We trust you have received the usual lecture from the local System
Administrator. It usually boils down to these three things:

    #1) Respect the privacy of others.
    #2) Think before you type.
    #3) With great power comes great responsibility.

Password:
# Network UPS Tools: example ups.conf
#
# --- SECURITY NOTE ---
#
# If you use snmp-ups and set a community string in here, you
# will have to secure this file to keep other users from obtaining
# that string.  It needs to be readable by upsdrvctl and any drivers,
# and by upsd.
#
# ---
#
# This is where you configure all the UPSes that this system will be
# monitoring directly.  These are usually attached to serial ports, but
# USB devices and SNMP devices are also supported.
#
# This file is used by upsdrvctl to start and stop your driver(s), and
# is also used by upsd to determine which drivers to monitor.  The
# drivers themselves also read this file for configuration directives.
#
# The general form is:
#
# [upsname]
#       driver = <drivername>
#         port = <portname>
#    < any other directives here >
#
# The section header ([upsname]) can be just about anything as long as
# it is a single word inside brackets.  upsd uses this to uniquely
# identify a UPS on this system.
#
# If you have a UPS called snoopy, your section header would be "[snoopy]".
# On a system called "doghouse", the line in your upsmon.conf to monitor
# it would look something like this:
#
#     MONITOR snoopy@doghouse 1 upsmonuser mypassword master
#
# It might look like this if monitoring in slave mode:
#
#     MONITOR snoopy@doghouse 1 upsmonuser mypassword slave
#
# Configuration directives
# ------------------------
#
# These directives are common to all drivers that support ups.conf:
#
#  driver: REQUIRED.  Specify the program to run to talk to this UPS.
#          apcsmart, bestups, and sec are some examples.
#
#    port: REQUIRED.  The serial port where your UPS is connected.
#          /dev/ttyS0 is usually the first port on Linux boxes, for example.
#
# sdorder: optional.  When you have multiple UPSes on your system, you
#          usually need to turn them off in a certain order.  upsdrvctl
#          shuts down all the 0s, then the 1s, 2s, and so on.  To exclude
#          a UPS from the shutdown sequence, set this to -1.
#
#          The default value for this parameter is 0.
#
#  nolock: optional, and not recommended for use in this file.
#
#          If you put nolock in here, the driver will not lock the
#          serial port every time it starts.  This may allow other
#          processes to seize the port if you start more than one by
#          mistake.
#
#          This is only intended to be used on systems where locking
#          absolutely must be disabled for the software to work.
#
# maxstartdelay: optional.  This can be set as a global variable
#                above your first UPS definition and it can also be
#                set in a UPS section.  This value controls how long
#                upsdrvctl will wait for the driver to finish starting.
#                This keeps your system from getting stuck due to a
#                broken driver or UPS.
#
#                The default is 45 seconds.
#
#
# Anything else is passed through to the hardware-specific part of
# the driver.
#
# Examples
# --------
#
# A simple example for a UPS called "powerpal" that uses the megatec
# driver on /dev/ttyS0 is:
#
# [powerpal]
#    driver = megatec
#    port = /dev/ttyS0
#    desc = "Web server"
#
# If your UPS driver requires additional settings, you can specify them
# here.  For example, if it supports a setting of "1234" for the
# variable "cable", it would look like this:
#
# [myups]
#     driver = mydriver
#    port = /dev/ttyS1
#    cable = 1234
#    desc = "Something descriptive"
#
# To find out if your driver supports any extra settings, start it with
# the -h option and/or read the driver's documentation.

pollinterval = 5

[ups]
    driver = usbhid-ups
    port = auto
    #pollonly
    #community = name
    #snmp_version = v2c
    #mibs = auto
    #secName = Synology
    #secLevel = noAuthNoPriv
    #authProtocol = MD5
    #authPassword = xxx
    #privProtocol = DES
    #privPassword = xxx
Rob@Dragon:/$ sudo cat /usr/syno/etc/ups/upsd.conf
LISTEN 0.0.0.0
Rob@Dragon:/$ sudo cat /usr/syno/etc/ups/upsd.users
# Network UPS Tools: Example upsd.users
#
# This file sets the permissions for upsd - the UPS network daemon.
# Users are defined here, are given passwords, and their privileges are
# controlled here too.  Since this file will contain passwords, keep it
# secure, with only enough permissions for upsd to read it.

# --------------------------------------------------------------------------

# Each user gets a section.  To start a section, put the username in
# brackets on a line by itself.  To set something for that user, specify
# it under that section heading.  The username is case-sensitive, so
# admin and AdMiN are two different users.
#
# Possible settings:
#
# password: The user's password.  This is case-sensitive.
#
# --------------------------------------------------------------------------
#
# actions: Let the user do certain things with upsd.
#
# Valid actions are:
#
# SET    - change the value of certain variables in the UPS
# FSD   - set the "forced shutdown" flag in the UPS
#
# --------------------------------------------------------------------------
#
# instcmds: Let the user initiate specific instant commands.  Use "ALL"
# to grant all commands automatically.  There are many possible
# commands, so use 'upscmd -l' to see what your hardware supports.  Here
# are a few examples:
#
# test.panel.start    - Start a front panel test
# test.battery.start    - Start battery test
# test.battery.stop    - Stop battery test
# calibrate.start    - Start calibration
# calibrate.stop    - Stop calibration
#
# --------------------------------------------------------------------------
#
# Example:
#
#    [admin]
#        password = mypass
#        actions = SET
#        instcmds = ALL
#

#
# --- Configuring for upsmon
#
# To add a user for your upsmon, use this example:
#
#    [upsmon]
#        password  = pass
#        upsmon master
# or
#        upsmon slave
#
# The matching MONITOR line in your upsmon.conf would look like this:
#
# MONITOR myups@localhost 1 upsmon pass master    (or slave)
[monuser]
        password = secret
        upsmon master
Rob@Dragon:/$

So Synology still uses NUT and have embedded it in DSM7.0. The only thing they have done with the GUI is try and neuter it so that only a single vendor is pushed to the end user, to exclude all others.

In doing so they have broken the licence terms of the GNU Public License for what is a community-maintained free and open source code for the NUT project.

A very naughty Synology Inc.
 
WTaF? That’s ridiculous! How the hell can I turn my NAS back on if I’m away from home? It renders all the remote access possibilities, including VPN, completely useless.

remote access via the VPN on the NAS?
Oh, wait, its turned off…

If the NAS is powered it can just plug itself in, when plugged-in it can power itself, just like how a lightbulb works...

light-bulb.jpg


...err, hang on a minute!!
 
Unless you run VPN services on the router. But even then it's not ideal, nor cheap.
I'll have to investigate some smart plugs, assume they can be accessed via Google Home, not ideal though, just something else to go wrong, maybe send synology the bill.
 
The only thing they have done with the GUI is try and neuter it so that only a single vendor is pushed to the end user, to exclude all others.
How would we "unbreak" this shenanigan?

Robbie said:

In doing so they have broken the licence terms of the GNU Public License for what is a community-maintained free and open source code for the NUT project.
How to report this?
 
I'll have to investigate some smart plugs, assume they can be accessed via Google Home, not ideal though, just something else to go wrong, maybe send synology the bill.

I like the idea of a sending Synology a bill but the functionality is still there, just not on the GUI.

A suitable script can probably be added (as that capability is still included in the GUI) to issue the relevant commands to all NUT-compliant devices and it should survive DSM updates. The other option is setting NUT via SSH configuration commands (as above) but Synology may try and be difficult and wipe these files clean on each DSM revision.
 
I'm still on DSM Classic on my main NAS, trusting DSM7.0 only on 2 tertiary NASes. At least DSM7.0 will still take the UPS commands from the DSM6 unit.

The irony in this is that my Syno NAS is/was the most reliable device to recover, in a managed way, from the secondary impacts of a power outage or spike. So much so that I have scripts on the main NAS to kick all my other devices back into life, or just 1 at a time. This includes clients such as Macs and even a Windows server that can be awkward at times:

Code:
synonet --wake 00:11:32:aa:aa:aa eth4;
synonet --wake 00:30:93:aa:aa:aa eth4;
synonet --wake d0:81:7a:aa:aa:aa eth4;
synonet --wake 98:fa:9b:aa:aa:aa eth4;

##eth 4 = LAN 5 = 10 GbE outgoing port##
##synonet --wake <MAC address of device to wake> eth<outgoing port eg LAN1 = eth0>##

From a Synology feature to a Synology failure.
 
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:
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?
 
I've got a NAS I can sacrifice for testing purposes. Whilst I grew-up during the zenith of such skills it with regret that my 'nix and CLI powers have atrophied to a point where the venerable BBC Micro & Apple IIe that I once sat behind would shun me.

If someone could prepare the commands and/or scripts and tolerate my efforts then the NAS awaits.
 

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.

Welcome to SynoForum.com!

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

Registration is free, easy and fast!

Back
Top