This topic has been marked solved and closed to new posts due to inactivity. We hope you'll join the conversation by posting to an open topic or starting a new one.
the problem being that it crashes out with a hard shutdown, so endangering any data and being no better than what happens when the NAS is powered off the mains and a power cut occurs.
Maybe download the logs and check what it does.
In my two recent tests, such shutdowns did not require it to resync or anything when it came back up. I assumed (hmmm) it did a clean panic shutdown, ie flushing caches etc. [he says going to look at his logs...]
When my NAS is not communicating with the UPS (my above posts) it doesn't shutdown.
When it is, briefly after I change a setting, it does, but does it properly, i.e.
Sat Nov 19 2016 10:24:54 System: ReadyNASOS service or process was restarted. Sat Nov 19 2016 10:18:01 System: UPS UPS () battery is low. System will shut down soon. Sat Nov 19 2016 10:16:29 System: UPS UPS () is on battery power.
So I suspect your problem may be different. But as someone said above, they do seem to have stuffed this area fairly well...
In my two recent tests, such shutdowns did not require it to resync or anything when it came back up. I assumed (hmmm) it did a clean panic shutdown, ie flushing caches etc. [he says going to look at his logs...]
The logs shown under the System / Logs tab don't show anything. Are there any other Logs?
System/Logs Download_logs button on the left. Unzip check sysem.log (and generally look around at others). ups.log for me was almost empty.
[note I'm just another user here]
Ah yes, lots and lots of logs!! Having a quick look, it seems the NAS could, just possibly, be doing a very fast but 'graceful' shutdown, or not, as the case may be. Only NetGear will know. If they want me to send them any logs, I have them ready.
Model: RN10400|ReadyNAS 100 Series 4- Bay (Diskless)
Did you receive similar UPS communication error messages with previous versions of the firmware? What is the output of 'upsc UPS' from the RN316 during the error periods?
Sat Nov 19 12:39:07 EST 2016 UPS Communication error. Sat Nov 19 10:25:18 EST 2016 Communication with UPS OK.
Ah yes, lots and lots of logs!! Having a quick look, it seems the NAS could, just possibly, be doing a very fast but 'graceful' shutdown, or not, as the case may be. Only NetGear will know. If they want me to send them any logs, I have them ready.
We haven't been able to reproduce the issue here, would you be willing to adjust some UPS server settings manually and see if there is any improvement?
Try reducing the polling frequency by adding "pollinterval = 10" to /etc/nut/ups.conf, then running "systemctl nut-driver restart". Changing UPS settings in the UI may overwrite these settings, so try not to do that.
So it seems that after a reboot /etc/nut/ups.conf gets overwritten/recreated In order to maintain those configuration changes we need to create an alternate configuration file and have the nut daemon use it.
Here's what I did:
Connecting to my NAS using ssh, I edited (using vi) /lib/systemd/system/nut-driver.service to look like this:
(notice the line starting with Environment right after [Service]: this line changes the path containing configuration files to /etc/nuts)
Next, I created a copy of the /etc/nut directory in /etc/nuts (this way if the original ups.conf file is overwritten we won't care)
cp -r /etc/nut /etc/nuts
Next, I've modified the file /etc/nuts/ups.conf (that's the copy we made in /etc/nuts) and added these two lines (Note: in my previous post I made a mistake since pollinterval is not supported by the usbhid-ups driver):
synchronous = yes
pollonly = yes
In my case the resulting file looks like this now:
The documentation for the pollonly flag says that "If this flag is set, the driver will ignore interrupts it receives from the UPS (not recommended, but needed if these reports are broken on your UPS). "
For the synchronous flag, the documentation says " The driver work by default in asynchronous mode (i.e synchronous=no). This means that all data are pushed by the driver on the communication socket to upsd (Unix socket on Unix, Named pipe on Windows) without waiting for these data to be actually consumed. With some HW, such as ePDUs, that can produce a lot of data, asynchronous mode may cause some congestion, resulting in the socket to be full, and the driver to appear as not connected."
You can test the configuration by restarting the daemon with:
Not the whole make a second copy change, I don't reboot often
It has now been over two hours without an error message.
system.log shows below, and no errors.
Dec 01 14:36:31 ME-NAS-316A usbhid-ups[9184]: Startup successful Dec 01 14:36:33 ME-NAS-316A upsd[6853]: Connected to UPS [UPS]: usbhid-ups-UPS Dec 01 14:36:40 ME-NAS-316A msmtpq[9199]: mail for [ -C /etc/msmtprc michael...@...com.au --timeout=60 ] : send was successful Dec 01 14:38:32 ME-NAS-316A upsd[6853]: User monuser@192.168.1.10 logged into UPS [UPS]
The mail was the Comms OK msg.
I unplugged the UPS, it behaved as expected. Got the frontview status changes, emails and the network monitoring of the NV+ too.
So that should do until a fix gets released.
Stll happy for a remote session if someone from NG wants to look around.
Were both of these options needed or does it still fail when only of them are applied? We can add this fix to the firmware, but need to know if both are required since we can't reproduce it here.
NON-WORKING CONFIGURATIONS synchronous = yes Hangs after a while, and I periodically got the following message in the log: libusb_get_interrupt: Connection timed out
no-additional parameters (default config) Logs show libusb_get_interrupt: Connection timed out After some time 'upsc UPS' returns Data stale
Test a. No errors for > 2 hours, b. correct behaviour when UPS unplugged.
Same, general results as @slashdotted, different errors (no timeout error):
Individually:
synchronous=yes - fail
Dec 02 16:45:22 ME-NAS-316A usbhid-ups[25161]: Startup successful Dec 02 16:45:24 ME-NAS-316A upsd[29633]: Connected to UPS [UPS]: usbhid-ups-UPS Dec 02 17:25:42 ME-NAS-316A upsd[29633]: Data for UPS [UPS] is stale - check driver Dec 02 17:25:42 ME-NAS-316A upsmon[29636]: Poll UPS [UPS@localhost] failed - Data stale
pollonly=yes - pass
pollinterval=5 - pass
For me, I think pollinterval=5 would be better as pollonly=yes ignores interrupts, which are apparently working on my UPS.
BTW, if my reading is correct, the pollfreq=30 has the USB driver wait 30 seconds between polls, listening for interrupts, while pollinterval is the delay between upsd 'updating the status'. Thus pollinterval shorter than pollfreq/2 (ie on average) will only be benificial in upsd picking up interupts prior to the next poll.So, in the bigger picture, a few seconds doesn't matter when power fails, a higher pollinterval may be called for. It only really affects reporting of UPS status, and that is only meaningfull when it is discharging, or less so, when recharging. [question is what types of messages the UPS sends unsolicited, i.e. via interrups?]
So I can't see why a pollinterval<15 is of much use. Even a pollinterval=9, will check for changes ~3 times per poll.
pollonly=yes 'ignore interrupts it receives from the UPS', presumably does not affect pollfreq, but without interrups power notification is delayed, thus the question of whether pollfreq should perhaps be shortened? The above pollinterval considerations apply. So, for example, pollfreq=10 & pollinterval=5, or (15/5, 10/3?) should be considered, and tested.
In order to maintain those configuration changes we need to create an alternate configuration file and have the nut daemon use it.
