NoRaid99

@volcs0 When in my system NUT is not working anymore, then it is allways the loss of usb connection. Don't know how your ups is attached to the server. But if you log then it is a good chance to find something there.

Yesterday I updated my three servers from 7.2.6 to 7.3.1. (Qnap TS-253d, 2700x and 3700x B450) All have running dockers and VM's. Everything is woking without any problems and like expected! About internal boot: How do you deal with when you have to rollback a release because of problems and the server wont start or not accessible anymore? With a pen drive this is easy, but with internal drive?

@MothyTim In my setting this is at zero as well and shutdown of the UPS is working. edit: sorry that I can't really help you. Maybe there is something to find in the logs, when you cut power and see what gets logged. Or have a try with driver 2.8.4 edit2: May 28 16:03:24 QNAP ool www[2808853]: /usr/local/emhttp/plugins/nut-dw/scripts/start May 28 16:03:25 QNAP rc.nut: Writing NUT configuration... May 28 16:03:28 QNAP rc.nut: Updating permissions for NUT... May 28 16:03:28 QNAP rc.nut: Checking if the NUT Runtime Statistics Module should be enabled... May 28 16:03:28 QNAP rc.nut: Disabling the NUT Runtime Statistics Module... May 28 16:03:29 QNAP rc.nut: Network UPS Tools upsdrvctl - UPS driver controller 2.8.4 release May 28 16:03:29 QNAP rc.nut: Network UPS Tools 2.8.4 release - Generic HID driver 0.67 May 28 16:03:29 QNAP rc.nut: USB communication driver (libusb 1.0) 0.50 May 28 16:03:29 QNAP rc.nut: Using subdriver: CyberPower HID 0.84 May 28 16:03:29 QNAP rc.nut: Defaulting 'pollfreq' to 12 for CPS devices May 28 16:03:29 QNAP usbhid-ups[2812862]: Defaulting 'pollfreq' to 12 for CPS devices May 28 16:03:29 QNAP usbhid-ups[2812862]: You may want to set 'pollonly' flag on CPS devices May 28 16:03:29 QNAP rc.nut: You may want to set 'pollonly' flag on CPS devices May 28 16:03:29 QNAP usbhid-ups[2812862]: Listening on socket /var/run/nut/usbhid-ups-ups May 28 16:03:29 QNAP rc.nut: Listening on socket /var/run/nut/usbhid-ups-ups May 28 16:03:29 QNAP usbhid-ups[2812864]: Startup successful May 28 16:03:30 QNAP rc.nut: Network UPS Tools upsd 2.8.4 release May 28 16:03:30 QNAP rc.nut: listening on 0.0.0.0 port 3493 May 28 16:03:30 QNAP upsd[2812898]: listening on 0.0.0.0 port 3493 May 28 16:03:30 QNAP upsd[2812898]: Connected to UPS [ups]: usbhid-ups-ups May 28 16:03:30 QNAP rc.nut: Connected to UPS [ups]: usbhid-ups-ups May 28 16:03:30 QNAP usbhid-ups[2812864]: sock_connect: enabling asynchronous mode (auto) May 28 16:03:30 QNAP upsd[2812898]: Found 1 UPS defined in ups.conf May 28 16:03:30 QNAP rc.nut: Found 1 UPS defined in ups.conf May 28 16:03:30 QNAP upsd[2812899]: Startup successful May 28 16:03:30 QNAP rc.nut: Network UPS Tools upsmon 2.8.4 release May 28 16:03:30 QNAP rc.nut: UPS: [email protected] (primary) (power value 1) May 28 16:03:30 QNAP rc.nut: Using power down flag file /etc/nut/killpower May 28 16:03:30 QNAP upsmon[2812902]: Startup successfulThats the normal log from unraid when starting nut service, maybe you find something missing at yours. edit3: WARNING: In most cases it is sufficient to configure NUT using the GUI for the smoothest possible user experience. Any changing the configuration directly can have unexpected side effects, use 'Reset Config' in case of problems. Have you checked the debug file? NUT Debug Package (.zip) In my setup upsmon.conf.txt shows POWERDOWNFLAG "/etc/nut/killpower" I guess driver.flag.allow.killpower will be set just in time when needed as variable. The description for the command: Tell the driver daemon to initiate UPS shutdown; should be unlocked with driver.flag.allow_killpower option or variable setting.

Does your UPS support this switch-off function after auto shutdown the server?

Don't think so. If the cells do not get charged up to 100% some times, there will be no satisfactory balancing. At least 3.5-3.55V per cell is needed for this to even start the process. And it needs as well a minimum amount of Amps to realise a effective balancing. Here I see as well a problem with the low charging current used for the small lead acid bateries used in UPS. That is marketing speak. Lead-acid-bat can never be the the same like LiFe-bat. and only can be replaced with compromises. They are basically different and are coosen by purpose. It is like running your diesel car with sunflower oil. Just don't do it, if you don't know exactly what you are doing.

Good point. And what about the cut off voltage? Anyway, personally I wouldn't do it. edit: -like this they never get balanced!!! -perhaps the Max. Continuous Discharge Current is not high enought -perhaps the Recommended charging current is not set to the right value and could be to high -possibly the lead-bat. gets charged sometimes with more then the 13.6V. Usualy 14.2V would be the voltage to keep lead-bat. at charge level.

@Rysz Okay, thank you for the explanation. Never have seen this before. Still seems to be a bit strange to me when the UPS reports "OB or CAL" while a power interruption. Who, if not the UPS itself knows what happened?

I see a other big problem when replacing Lead-Bat. to Li-Bat. for UPS. Keeping them constantly at 100% charging level is realy bad. I would say it is a security risk. If you go for Li-Bat. then buy a UPS that is build for that.

Nice helpful tool, thanks for your work! @jcofer555 One thing I want to comunicate is that I would like the possibility to choose a light theme, because of my eye-problems. It is possible to stand it, because I do not spend much time on the applications-page, but would be helpful anyway. Perhabs for other people as well.

because of the security updates: Updated from 7.2.4 to 7.2.6 without any problems on a TS-253d with lots of dockers and a few Linux VMs. To keep the same old mac adresses of the docker conainers I did stop all dockers before the update, unticked the "auto start", updated and rebooted. Then it is important to change the templates from the docker containers before they start the first time and set the old fixed MAC. This way all did stay the same like before. I really don't hope that we soon have to update every week because of security fixes. 🤞

Hi all, there is a log generated while having power problems/cuts from my UPS and I would need help to understand what this means: May 7 02:32:56 QNAP usbhid-ups[3710]: ups_status_set: seems that UPS [ups] is in OL+DISCHRG state now. Battery charge is currently 87. Is it calibrating (perhaps you want to set 'onlinedischarge_calibration' option)? Note that some UPS models (e.g. CyberPower UT series) emit OL+DISCHRG when in fact offline/on-battery (perhaps you want to set 'onlinedischarge_onbattery' option) The UPS is a CP1500EPFCLCD (not UT series). OL+DISCHRG means what? overload and discharge? I'm asking because I'm trying to observe nasty power problems on my private source (off-grid-inverter) and have seen this entry in the server.log. thanks in advance noraid

I will report back, but do not have the time atm to update. There is to much "important" stuff on that server.

Brand: Seagate Model: ST8000DM004-2CX188 Approximate age at failure: 5 years Drive in warranty: never Origin: cheap buy out of a external USB case Because the drives are only for redundancy of a backup-server and lak of money, I did buy the cheapest I could get. Don't have the drive connected to a computer atm, but the drive has only very little working hours and read/write values, because this server gets started only once a week and there are no big changes to backup. I post here because this disk made me cracy and I want to share my experience with it. Since a long time I do have copy/speed problems on network when this server is in use. Funny erros like network errors. Sometimes all was fine, sometimes I had to restart network or the server. There was never any indication for the cause. I changed nearly everything and testet and testet... no errors at all in log. Before a month, I did rebuild the server with the same HW, but new boot media and it started to show up some errors sometimes. PCIe errors, network errors, funny self reboots of the server, only when there was action on this specific disk. Then I was checking this disk with full SMART test, Seagate extended tests, preclear with read-write-read, but all was perfect! But finally it is this blo..y disk causing all these funny errors and no test type could find something unusual.

@jademonkee ,thanks a lot for your answer. I think this makes sense like you explained and hope somebody can confirm, if so. In v.7.2.4 and before, (in my case - container MAC with active NetworkType: custom: eth0 and specified local IP) , the first generated MAC did persit every reboot and update of the container. This is important for me because DHCP and firewall settings. So, if I'm right, from now on I do have to: This creates a new question, if I stop docker, deactivate auto start and update to 7.4.5, set the new value MAC Adress in the template, will it be possible somehow to keep the old MAC?