UPS problem. Install regular NUT server?

[nickba]

Hello everyone.
I hope someone could help me with my APC ES600 ups.
I am having a weird issue. DSM 7, latest official version and Xeon CPU:
When I connect my ups using the USB cable, it works and after a couple hours it’s stops refreshing the data. So Synology still thinks it is connected and working. But if a power failure occurs, it will not go to safe mode as it is not refreshing the ups status.
So, I made a test: I created a virtual Debian machine and installed nut(version 2.7.4).
I stopped the nut service in the Synology, so it would not pickup the USB connection.
The nut server on the virtual machine is working perfectly. So it rules out any problems with the ups or usb connection. So seems that the nut server with my APC ups in DSM 7 is broken.
Do you know if it is possible to configure the nut server in Synology with my own conf files? I am asking that, because I tried and Synology overwrites them. Or maybe a way to install the regular nut server and use it instead of the built in one.

 

[Robbie]

Not a great deal of info for us to ponder but we have seen issues with DSM's version of NUT before, albeit not recently.

Could you post the NUT config files and upsc from your physical machine - they are all in the standard NUT format on the CLI?

Config via this command:

sudo cat /usr/syno/etc/ups/ups.conf

upsc via this command:

upsc ups@servername

My upsc looks like this:

Rob@R:~$ upsc ups@r
Init SSL without certificate database
battery.capacity: 9.00
battery.charge: 100
battery.charge.low: 20
battery.charge.restart: 20
battery.charger.status: resting
battery.energysave: no
battery.energysave.delay: 300
battery.energysave.load: 5
battery.protection: yes
battery.runtime: 932
battery.type: PbAc
battery.voltage: 13.0
battery.voltage.nominal: 12
device.mfr: EATON
device.model: 5P 650
device.serial: G114L50095
device.type: ups
driver.name: usbhid-ups
driver.parameter.pollfreq: 30
driver.parameter.pollinterval: 5
driver.parameter.port: auto
driver.parameter.synchronous: no
driver.version: DSM7-1-1-42930-workplus-version2-repack-42930-220712
driver.version.data: MGE HID 1.39
driver.version.internal: 0.41
input.current: 1.10
input.frequency: 49.9
input.frequency.extended: yes
input.frequency.nominal: 50
input.sensitivity: low
input.transfer.boost.low: 192
input.transfer.high: 294
input.transfer.low: 167
input.transfer.trim.high: 276
input.voltage: 248.0
input.voltage.extended: no
input.voltage.nominal: 230
outlet.1.autoswitch.charge.low: 0
outlet.1.delay.shutdown: 65535
outlet.1.delay.start: 10
outlet.1.desc: PowerShare Outlet 1
outlet.1.id: 1
outlet.1.status: on
outlet.1.switchable: yes
outlet.2.autoswitch.charge.low: 0
outlet.2.delay.shutdown: 65535
outlet.2.delay.start: 10
outlet.2.desc: PowerShare Outlet 2
outlet.2.id: 2
outlet.2.status: on
outlet.2.switchable: yes
outlet.desc: Main Outlet
outlet.id: 0
outlet.switchable: no
output.current: 1.00
output.frequency: 49.9
output.frequency.nominal: 50
output.powerfactor: 0.52
output.voltage: 248.0
output.voltage.nominal: 240
ups.beeper.status: disabled
ups.delay.shutdown: 20
ups.delay.start: 30
ups.efficiency: 91
ups.firmware: 02.14.0026
ups.load: 38
ups.load.high: 105
ups.mfr: EATON
ups.model: 5P 650
ups.power: 248
ups.power.nominal: 650
ups.productid: ffff
ups.realpower: 130
ups.realpower.nominal: 420
ups.serial: G114L50095
ups.shutdown: enabled
ups.start.auto: yes
ups.start.battery: yes
ups.start.reboot: no
ups.status: OL
ups.test.interval: 2592000
ups.test.result: Done and passed
ups.timer.shutdown: 0
ups.timer.start: 0
ups.type: offline / line interactive
ups.vendorid: 0463
Rob@Rivendell:~$

️

 

[Deleted member 5784]

Hello everyone.
...
When I connect my ups using the USB cable, it works and after a couple hours it’s stops refreshing the data. So Synology still thinks it is connected and working. But if a power failure occurs, it will not go to safe mode as it is not refreshing the ups status.

Could you explain more about this part? Where are you looking for data? What are the symptoms of it not refreshing? I presume you've actually tested this by pulling the mains supply to the UPS - could you give us more detail about exactly what happened when you pulled the plug?

 

[nickba]

Hello Robbie and Fortran, thank you for replying!

First, let me give you more detailed information. I know it is not refreshing the UPS status after a couple hours, because if I pull the plug after this time, it will not go to sleep mode. So I kept checking the upsc ups and I noticed it was not refreshing the ups status after a couple hours. After that I checked the dmesg output and sure enough there was a lot of errors:

usbfs: USBDEVFS_CONTROL failed cmd usbhid-ups rqt 161 rq 1 len 4 ret -71

Now, here are the output from the commands:
My ups.conf is not located at /usr/syno/etc/ups/ups.conf. At this location, there is only the synoups.conf.

Here is the cat /etc/ups/ups.conf:

root@NAS:~# cat /etc/ups/ups.conf
# 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 =
        #snmp_version = v2c
        #mibs =
        #secName =
        #secLevel =
        #authProtocol =
        #authPassword =
        #privProtocol =
        #privPassword =

And here is the upsc ups command:

root@NAS:~# upsc ups
Init SSL without certificate database
battery.charge: 100
battery.charge.low: 10
battery.charge.warning: 50
battery.date: 2001/09/25
battery.mfr.date: 2023/03/02
battery.runtime: 1260
battery.runtime.low: 120
battery.type: PbAc
battery.voltage: 13.8
battery.voltage.nominal: 12.0
device.mfr: APC
device.model: Back-UPS ES 600P
device.serial: 5B1206T06783
device.type: ups
driver.name: usbhid-ups
driver.parameter.pollfreq: 30
driver.parameter.pollinterval: 5
driver.parameter.port: auto
driver.parameter.synchronous: no
driver.version: DSM7-1-1-42930-workplus-version2-repack-42930-220712
driver.version.data: APC HID 0.96
driver.version.internal: 0.41
input.sensitivity: medium
input.transfer.high: 143
input.transfer.low: 88
input.voltage: 126.0
input.voltage.nominal: 115
ups.beeper.status: disabled
ups.delay.shutdown: 20
ups.firmware: 897.Q3 .D
ups.firmware.aux: Q3
ups.load: 27
ups.mfr: APC
ups.mfr.date: 2012/02/13
ups.model: Back-UPS ES 600P
ups.productid: 0002
ups.realpower.nominal: 360
ups.serial: 5B1206T06783
ups.status: OL
ups.test.result: No test initiated
ups.timer.reboot: 0
ups.timer.shutdown: -1
ups.vendorid: 051d

 

[Robbie]

usbfs: USBDEVFS_CONTROL failed cmd usbhid-ups rqt 161 rq 1 len 4 ret -71

Short answer is - I don't know. It looks like a comms error, which tends not to be an actual error but a higher priority task preventing the UPS CPU from passing a message, which is then interpreted as a comms failure.

You could delay the polling rate in an effort to get correct messages out but this will also slow state-change messages.

Clearly try different USB ports and cables but I think the UPS is not playing nicely. It looks to be an old model so perhaps there is a new firmware available for it?

️

 

[Deleted member 5784]

I agree with @Robbie; it appears to be a comms problem between the UPS & the Syno.

The pollinterval defaults to 2s, so 5s should be ok.

I'm wondering if the 'auto' setting in ups.conf is somehow losing track of the correct USB port...you could try specifying the USB port of the Syno rather than leaving it to 'auto'. iirc USB ports on Synos take the form '/dev/ttyUSB0' (check this). So your ups.conf would read port = /dev/ttyUSB0 (or whatever ).

I'm assuming that you dont have anything weird like a USB hub in between the UPS & the NAS?

Beyond that, I'm a little stuck. Is the CPU on the NAS under very heavy load when it loses sight of the USB port?

 

[nickba]

Hi, thanks for replying.
The CPU never reaches 15% load. So it is not that. There is no newer firmwares for this UPS.
The most interesting fact, like I reported in the first post, is the Debian VM I installed on the same NAS works perfectly with nut and this UPS! I just need to stop the Synology nut process with the command:

systemctl stop ups-usb

After that I just connect the UPS usb through the VM to Debian and it works. I tested it for days. Not a single error.
So that proves it is not the UPS or the USB port or cable.
But I tested on other USB ports anyway and with the Synology factory installed nut, I get the same problem.

Here is the ups.conf I used with the Debian VM that works fine:

maxretry = 3

[ups]
    driver = usbhid-ups
    port = auto
    desc = "APC ES600"
    vendorid = 051d
    productid = 0002
    serial = 5B1206T06783

As you can see, I did not set the poll interval, so it is running on the default value, which is 2 seconds, which is less than the Synology 5 seconds and even with this short poll interval it works fine! And I am also using the port=auto.
The only USB device connected to the NAS is the UPS.


Maybe there is a way to install the regular nut server on Synology? As the regular one(2.7.4) works on a VM running on the Synology VMM on the same machine.

Any suggestions would be appreciated.

 

[Deleted member 5784]

The most interesting fact, like I reported in the first post, is the Debian VM I installed on the same NAS works perfectly with nut and this UPS! I just need to stop the Synology nut process with the command:

systemctl stop ups-usb

After that I just connect the UPS usb through the VM to Debian and it works. I tested it for days. Not a single error.
So that proves it is not the UPS or the USB port or cable.

The Syno appears to be losing the connection to the USB port on the UPS after a period of time. It may not be the USB port or cable, but the issue could be a software bug in the (very old) version of the NUT driver that Syno uses; for that reason, imo it is still worth trying the defined port I suggested rather than the 'auto' setting.

The last time I looked Synology DSM 7 uses NUT v 2.6.n. NUT v2.7.1 was released in 11/2013, so the Syno version is at least 9.5 years old!

Maybe there is a way to install the regular nut server on Synology? As the regular one(2.7.4) works on a VM running on the Synology VMM on the same machine.

Any suggestions would be appreciated.

Afraid I can't help you here; Synology add proprietary deviations such as non-standard paths and dependencies on extremely old pkg versions which makes installing standard Linux packages & paths extremely difficult. You'd need to know these variations in detail in order to install a standard NUT package and get it working on the Syno.

 

[nickba]

Hi Fortran,

Thanks again for replying. I am willing to try to define the USB port manually, but do you know how can I make the changes in the /etc/ups/ups.conf to stay? As they are overwritten by Synology...

 

[Deleted member 5784]

I think the ups.conf gets overwritten when DSM gets upgraded. We could make it permanent with, eg, a sed script that runs after boot, or that you manually run after a DSM update.

But worry about that later. Try the user-defined port first and then see if it fixes your issue. We only need to worry about making the fix permanent if it works.

 

[Deleted member 5784]

One other check you could make is running lsusb after the NAS stops communicating with the UPS. Is your UPS USB still listed in the output?

 

[nickba]

I think the ups.conf gets overwritten when DSM gets upgraded. We could make it permanent with, eg, a sed script that runs after boot, or that you manually run after a DSM update.

But worry about that later. Try the user-defined port first and then see if it fixes your issue. We only need to worry about making the fix permanent if it works

Hi, actually Synology overwrites it as soon as I start the ups-usb process.

One other check you could make is running lsusb after the NAS stops communicating with the UPS. Is your UPS USB still listed in the output?

Yes, the UPS USB is still listed after the communication problem.

 

[Deleted member 5784]

Yes, the UPS USB is still listed after the communication problem.

Sounds like my 'disappearing USB' theory may not be correct then.

At this point there's no straightforward solution. If the Syno overwrites any changes to the usb.conf at process startup, we're fighting an uphill battle to even diagnose / research the problem. It could be an issue with the old NUT driver; it could also be a bug in the DSM 7 USB kernel drivers or a 'feature' of DSM 7's blocking of non-HDD & non-UPS USB devices. Ofc, the Debian VM comes with its own USB kernel drivers so this could be why the issue doesn't occur there.

If it was me and I wanted to stick with Syno I'd chalk this one up to the cost of using a Syno vs an open platform & just buy a recent, compatible UPS...

Good luck!

 

[nickba]

Thanks for trying to help, Fortran. Seems it copies the file located at

 /etc.defaults/ups/ups.conf

over the

etc/ups/ups.conf

So how can I find the path to the USB port my UPS is connected? I tried dmesg, but it does not show the path.
What do you think about installing the apcupsd and using its driver with nut? As nut already support that.
Do you have a clue how to install apcupsd on DSM 7?

 

[Deleted member 5784]

So how can I find the path to the USB port my UPS is connected? I tried dmesg, but it does not show the path.

Determine USB device file Path

How can i get USB device file path correctly in Linux. I used command: find / -iname "usb" and got the result as below: /dev/bus/usb /sys/bus/usb /sys/bus/usb/drivers/usb /sys/kernel/debug/usb Un...

stackoverflow.com

lsusb
Bus 002 Device 006: ID 051d:0002 American Power Conversion Uninterruptible Power Supply

This gives you the USB Bus & Device. Your device path is then /dev/bus/usb/<BUS>/<DEVICE>

The above were taken from an UBUNTU 22.04 LTS server; the Synology version of lsusb may be different but iirc the /dev/bus/usb/ path is the same.

What do you think about installing the apcupsd and using its driver with nut? As nut already support that.
Do you have a clue about how to install apcupsd on DSM 7?

Sorry, I have no experience of installing apcupsd.

 

[Deleted member 5784]

To view this content we will need your consent to set third party cookies.
For more detailed information, see our cookies page.

Accept third party cookies

View: https://www.reddit.com/r/synology/comments/xizho6/solved_nas_losing_connection_to_the_ups/

Could be worth trying an automatic reload of the upsd daemon...?

 

[nickba]

Hi Fortran, thanks for the link. Actually it was one of the first things I tried before posting here, but the problem with this workaround is if the power loss occurs during restart, the UPS would not shutdown(I tested it). But it will be the last resort...

 

[nickba]

Silly me, I didn't test the

 upsd -c reload

enough before. In my case it does nothing... Problems still there with the dmesg errosr after a while:

usbfs: USBDEVFS_CONTROL failed cmd usbhid-ups rqt 161 rq 1 len 4 ret -71

 

[Deleted member 5784]

You've probably seen this discussion (from 13 yrs ago!) which features a lot of information re the NUT error codes and debugging issues.

fwiw the error code you were getting in your post #4 above (71) is a 'protocol error', and is usually preceded by a different error eg a timeout (110).

The error in the thread I linked was down to a combination of a particular UPS (Eaton) overloading the NUT driver with data, and the driver not dealing with this event gracefully.
The errors reduced - but didn't completely disappear - when the UPS battery was replaced with a healthier one. This reduced the number of data events being generated and thus reduced the frequency of errors.

Not saying this is your issue, but is an example of the sort of specific, intractable issue that would be solved by just changing your UPS for a different brand/model that is known to work with the Syno 2.6 NUT.

 

[Telos]

Depressing thread. This motivates me to move NUT to my RPi.