Rysz

So is it fixed now or not after uninstalling NUT? Because you say the problem disappeared but yet you can't boot your system? Sorry I'm just trying to make sense of this, because it looks like your problem isn't resolved.

As written in the support topic where you claimed uninstalling NUT solved your problem (but didn't): This seems more of a general hardware or configuration problem, rather than one caused by NUT. I'd advise killing the power to your server at this stage, checking the HDD cables and running memtest. If you have any logs indicating an actual problem with NUT, I'll be happy to do my best to help you... 🙂

Nothing was changed in the backend between the last updates, only optical changes in the GUI. Can you provide logs from before you uninstalled the plugin, or perhaps a diagnostics package? 11 minutes ago you say "all works fine" after uninstalling NUT. Two minutes ago you say nothing works in another topic about your problem? 😐 This seems more of a general hardware or configuration problem, rather than one caused by NUT. If you have any logs indicating an actual problem with NUT, I'll be happy to do my best to help you... 🙂

Exos - würde immer nur Neuware kaufen gerade bei Festplatten.

Sind meine Festplatten der Wahl, hatte noch nie Probleme.

I personally consider UNRAID a system that always preferred the ease of use over security concerns and I just learned to treat it accordingly. Meaning that I only allow LAN access, share nothing to the internet, install no plugins that I don't trust and use restrictive Docker settings (e.g. for volume mounts, no privileged containers). I love UNRAID for its ease of use as a dataserver and wouldn't want to have it any other way, so requiring 2FA would mostly be an annoyance for me personally. Because as long as everything continues to run as root (which I like, as it makes administration much easier) the only thing that 2FA would accomplish - I think - is leading people into a false sense of security and making stupid decisions in the process... exposing unsecured services to the internet among the various possibilities. I continue to read posts where people ask for LTS versions (which keep getting "security updates"), calling for 2FA or other more advanced security mechanisms. It seriously makes me wonder what their expectations towards UNRAID are and if I'm the only one who doesn't have any such expectations. Because, myself, I want a rock stable dataserver for my LAN (or at most accessible over VPN) which works and requires minimum effort on my part - best case it runs without problems and I don't need to login for anything ever. I have UNRAID servers which still are on 6.8.3. with hundreds of days of uptime, zero issues and I've never been hacked or had any significant efforts from external parties to breach into my servers. I keep my network as secure as possible and apply a principle of no trust towards letting people on my network, which I think is the most important factor for me. I think many people try to make base UNRAID into some kind of "jack of all trades" that can do everything from hosting gameservers to crypto mining while 100% secure with all ports exposed to the internet but also having premium ZFS support and whatnot. For me that makes no sense and I compare it to preferring to eat at a restaurant which does fewer dishes excellently rather than one that offers 500 dishes which are all mediocre at best. There's various software for various use-cases, for me base UNRAID will always be an easy to use dataserver OS - for the rest I have VMs and other software. I'm not saying my personal view is the right one, just wanted to offer another perspective here. 🙂

I have just pushed an update which fixes your issue. The "UPS Name" setting now remains visible also in Manual Configuration mode, letting you set which of your configured UPS you want the GUI dashboards to show information for. At present you can only choose one UPS to display information for in the GUI (by setting the "UPS Name" to that configured UPS' name). Showing multiple UPS in the GUI requires a larger developmental effort so I'll have to put this on the TO-DO list for now. Hope that helps... 🙂

This actually seems to be a previously unknown shortcoming of the plugin when operating in manual configuration mode. I'm guessing that most people usually configure via the GUI and hence this problem hasn't surfaced any sooner. I'll take a look at possible solutions and will push an update once I have it figured out. In the meantime NUT itself should function normally, just in the background, even if the GUI shows nothing.

You can't, it's a diagnostic message built directly into NUT. It only means that it's checking for duplicate instances of NUT before starting up but couldn't find any (which is a good thing)... so it's safe to ignore this message. 🙂

You can use the UPSCMD command line tool included in NUT to invoke supported commands on your UPS - check this page for more information: https://networkupstools.org/docs/man/upscmd.html

I just updated from 6.12.5 to 6.12.6 and cannot reproduce the issue you described. There's also no reason my current version of NUT wouldn't work with version 6.12.6... Perhaps you were on some other deprecated version of NUT (maybe upgrading from a very old OS?) Please make sure to install the version by me (Rysz/desertwitch), which is the only actively maintained one.

Quick search returned this (admittedly very old, but possibly still relevant) mailing list conversation: https://nut-upsuser.alioth.debian.narkive.com/bUVt7nv2/cyberpower-usbhid-ups-continuously-disconnects-reconnects Might be a firmware issue in some CyberPower devices... I didn't read through all of it as I'm currently out, but looks a bit like your issue and maybe (or maybe not) provides some more clarity on it.

You can use the statistics "Variable Override" to display the variable "ups.realpower" instead (if your UPS reports it). This can be done under "NUT Settings" and then you'll have the chart display the watts.

Do you perhaps also have the APC service running (check "UPS Settings") ? The service in "UPS Settings" needs to be disabled, otherwise it'll interfere with NUT.

Glad to hear it - thanks for reporting back! 🙂

"UPS Settings" has nothing to do with NUT, it's a separate tool (apcupsd). In fact you should set "Start APC UPS daemon:" to "No" under "UPS Settings". NUT and apcupsd cannot run at the same time - they'll interfere with each other. Data stale warnings are usually USB timeouts and nothing to worry about. Broken pipe warnings always occur when killing the NUT service, that's normal too. So as long as everything works, "Start APC UPS daemon:" to "No" and you're all good.

It's on CA, but it's for UNRAID versions 6.10+, so your 6.8.3 (according to your signature) is too outdated. 😕

I'm very glad to hear it, thanks for your patience with this. I'll be including a warning message before starting "Auto Config" as part of the next update.

Thanks a lot for sending me the NUT debug packages with your respective configurations. I've just compared the two configurations and it seems the NUT Scanner (= "Auto Config") misdetected either your USB port's information or UPS device's information. As a consequence, particularly by writing that wrong information into the configuration file, the UPS driver then only tried connecting to a UPS with said wrong information (and not all other possible UPS combinations it otherwise knows). That's unfortunately one of the pitfalls when using "Auto Config". It aids detection, but makes the UPS driver "blind" to any other UPS devices it would usually otherwise know. I'll have to put this as a warning message somewhere, for more tricky UPS devices or UPS detection scenarios like yours. To further illustrate this, here we have the old ups.conf configuration (with "Auto Config"): driver = "usbhid-ups" port = "auto" vendorid = "06DA" productid = "FFFF" product = "Offline UPS" serial = "000000000" vendor = "PPC" bus = "001" device = "029" busport = "009" And this is the working new ups.conf configuration (without "Auto Config"): driver = usbhid-ups port = auto When all those vendorid, productid, bus, device, ... parameters are not given to the UPS driver it basically starts lock-picking all possible other combinations of any UPS devices it otherwise knows, instead of just trying that one UPS device that NUT Scanner (= "Auto Config") has given to it. That seems to have been successful in your case, by not pinning the UPS driver onto a specific USB port or UPS device it managed to autodetect it somehow else straight away. But in other cases it would need exactly that information we've now dropped to detect the UPS in the first place - so it remains a double-edged sword. So in your case please do not use "Auto Config" for that UPS (it doesn't seem to work well in this specific case) and best don't change any of the UPS Driver Settings anymore now that it works. It should then continue working even after a system reboot. 🙂 Users with similar troubles I would recommend to attempt "Reset Config" and then not use "Auto Config" straight away, but instead try their respective UPS Driver with UPS Port set to auto first.

Sorry there's not really much I can do about individual UPS device's compatibility with NUT. The limiting factor here are always the UPS drivers in the NUT backend, which is developed by other people and mostly with other operating systems in mind. Some UPS devices do work better with some older NUT backends, which you can choose using the Network UPS Tools Backend Switch. Apart from that all I can do here is help make sure that your NUT configuration is correct, which it seems to be in the above cases. Here's some more information for your device: https://networkupstools.org/ddl/PowerWalker/VI_1200_SH.html It seems to have worked with 2.7.4. at some point, so you could try with the legacy (2.7.4. stable) backend.

@ich777: So I just tested it with "Auto Update" (thanks for telling me where to find it 😄 ) Nov 7 12:26:01 Tower Plugin Auto Update: Checking for available plugin updates Nov 7 12:26:12 Tower Plugin Auto Update: Auto Updating nut-dw.plg Nov 7 12:26:21 Tower root: plugin: running: anonymous Nov 7 12:26:25 Tower upsmon[9189]: Signal 15: exiting Nov 7 12:26:25 Tower upsd[9184]: User [email protected] logged out from UPS [ups] Nov 7 12:26:25 Tower upsmon[9187]: upsmon parent: read Nov 7 12:26:25 Tower upsd[9184]: mainloop: Interrupted system call Nov 7 12:26:25 Tower upsd[9184]: Signal 15: exiting Nov 7 12:26:25 Tower dummy-ups[9170]: WARNING: send_to_all: write 34 bytes to socket 13 failed (ret=-1), disconnecting: Broken pipe Nov 7 12:26:27 Tower dummy-ups[9170]: Signal 15: exiting Nov 7 12:26:28 Tower root: plugin: checking: /boot/config/plugins/nut/nut-2.8.0-x86_64-12master.ssl11.txz - MD5 Nov 7 12:26:28 Tower root: plugin: skipping: /boot/config/plugins/nut/nut-2.8.0-x86_64-12master.ssl11.txz already exists Nov 7 12:26:28 Tower root: plugin: checking: /boot/config/plugins/nut/nut-2.8.1-x86_64-2stable.ssl11.txz - MD5 Nov 7 12:26:28 Tower root: plugin: skipping: /boot/config/plugins/nut/nut-2.8.1-x86_64-2stable.ssl11.txz already exists Nov 7 12:26:28 Tower root: plugin: checking: /boot/config/plugins/nut/nut-2.8.0-x86_64-1stable.ssl11.txz - MD5 Nov 7 12:26:28 Tower root: plugin: skipping: /boot/config/plugins/nut/nut-2.8.0-x86_64-1stable.ssl11.txz already exists Nov 7 12:26:28 Tower root: plugin: checking: /boot/config/plugins/nut/nut-2.7.4.20200318-x86_64-1.txz - MD5 Nov 7 12:26:28 Tower root: plugin: skipping: /boot/config/plugins/nut/nut-2.7.4.20200318-x86_64-1.txz already exists Nov 7 12:26:28 Tower root: plugin: running: anonymous Nov 7 12:26:28 Tower root: plugin: checking: /boot/config/plugins/nut/net-snmp-5.9.3-x86_64-1.txz - MD5 Nov 7 12:26:28 Tower root: plugin: skipping: /boot/config/plugins/nut/net-snmp-5.9.3-x86_64-1.txz already exists Nov 7 12:26:28 Tower root: plugin: running: upgradepkg --install-new /boot/config/plugins/nut/net-snmp-5.9.3-x86_64-1.txz Nov 7 12:26:28 Tower root: plugin: checking: /boot/config/plugins/nut/libmodbus-3.1.10-x86_64-1usb.txz - MD5 Nov 7 12:26:28 Tower root: plugin: skipping: /boot/config/plugins/nut/libmodbus-3.1.10-x86_64-1usb.txz already exists Nov 7 12:26:28 Tower root: plugin: running: upgradepkg --install-new /boot/config/plugins/nut/libmodbus-3.1.10-x86_64-1usb.txz Nov 7 12:26:28 Tower root: plugin: checking: /boot/config/plugins/nut/nut-plugin-2023.11.06-x86_64-1.txz - MD5 Nov 7 12:26:28 Tower root: plugin: skipping: /boot/config/plugins/nut/nut-plugin-2023.11.06-x86_64-1.txz already exists Nov 7 12:26:28 Tower root: plugin: running: upgradepkg --install-new /boot/config/plugins/nut/nut-plugin-2023.11.06-x86_64-1.txz Nov 7 12:26:28 Tower root: plugin: running: anonymous Nov 7 12:26:33 Tower dummy-ups[18158]: Startup successful Nov 7 12:26:34 Tower upsd[18168]: listening on 0.0.0.0 port 3493 Nov 7 12:26:34 Tower upsd[18168]: Connected to UPS [ups]: dummy-ups-ups Nov 7 12:26:34 Tower dummy-ups[18158]: sock_connect: enabling asynchronous mode (auto) Nov 7 12:26:34 Tower upsd[18168]: Found 1 UPS defined in ups.conf Nov 7 12:26:34 Tower upsd[18169]: Startup successful Nov 7 12:26:34 Tower upsmon[18172]: Startup successful Nov 7 12:26:34 Tower upsd[18169]: User [email protected] logged into UPS [ups] Nov 7 12:26:34 Tower root: plugin: nut-dw.plg updated Can't reproduce the problem here, seems to work as it should on NUT 2.8.1 even with "Auto Update". But I'll monitor this over the next few days and will also investigate it some more when pre-release/release candidate versions of 6.13 become available, I currently have no way to test those libssl3 versions apart from my Slackware 15.1 build environment where they work just fine. In general though I'd advise against auto-updating NUT because if problems (such as this one) occur during updating, they're more likely to be noticed only much later. Worst case the services don't come up as they should like here and a power failure occurs in that time-frame between the problem and the user noticing there's something wrong.

Did you also try "Reset Config" and then afterwards "Auto Config" again? If possible can you send me a PM with your debug package after "Auto Config" - it's on "NUT Settings" page:

Just ran it with a manual update and it started them back up just fine: Nov 7 12:12:24 Tower upsmon[2098]: Signal 15: exiting Nov 7 12:12:24 Tower upsd[2094]: User [email protected] logged out from UPS [ups] Nov 7 12:12:24 Tower upsmon[2097]: upsmon parent: read Nov 7 12:12:24 Tower upsd[2094]: mainloop: Interrupted system call Nov 7 12:12:24 Tower upsd[2094]: Signal 15: exiting Nov 7 12:12:25 Tower dummy-ups[2090]: WARNING: send_to_all: write 29 bytes to socket 8 failed (ret=-1), disconnecting: Broken pipe Nov 7 12:12:28 Tower dummy-ups[2090]: Signal 15: exiting Nov 7 12:12:28 Tower root: plugin: checking: /boot/config/plugins/nut/nut-2.8.0-x86_64-12master.ssl11.txz - MD5 Nov 7 12:12:28 Tower root: plugin: skipping: /boot/config/plugins/nut/nut-2.8.0-x86_64-12master.ssl11.txz already exists Nov 7 12:12:28 Tower root: plugin: checking: /boot/config/plugins/nut/nut-2.8.1-x86_64-2stable.ssl11.txz - MD5 Nov 7 12:12:28 Tower root: plugin: skipping: /boot/config/plugins/nut/nut-2.8.1-x86_64-2stable.ssl11.txz already exists Nov 7 12:12:28 Tower root: plugin: checking: /boot/config/plugins/nut/nut-2.8.0-x86_64-1stable.ssl11.txz - MD5 Nov 7 12:12:28 Tower root: plugin: skipping: /boot/config/plugins/nut/nut-2.8.0-x86_64-1stable.ssl11.txz already exists Nov 7 12:12:28 Tower root: plugin: checking: /boot/config/plugins/nut/nut-2.7.4.20200318-x86_64-1.txz - MD5 Nov 7 12:12:28 Tower root: plugin: skipping: /boot/config/plugins/nut/nut-2.7.4.20200318-x86_64-1.txz already exists Nov 7 12:12:28 Tower root: plugin: running: anonymous Nov 7 12:12:28 Tower root: plugin: checking: /boot/config/plugins/nut/net-snmp-5.9.3-x86_64-1.txz - MD5 Nov 7 12:12:28 Tower root: plugin: skipping: /boot/config/plugins/nut/net-snmp-5.9.3-x86_64-1.txz already exists Nov 7 12:12:28 Tower root: plugin: running: upgradepkg --install-new /boot/config/plugins/nut/net-snmp-5.9.3-x86_64-1.txz Nov 7 12:12:28 Tower root: plugin: checking: /boot/config/plugins/nut/libmodbus-3.1.10-x86_64-1usb.txz - MD5 Nov 7 12:12:28 Tower root: plugin: skipping: /boot/config/plugins/nut/libmodbus-3.1.10-x86_64-1usb.txz already exists Nov 7 12:12:28 Tower root: plugin: running: upgradepkg --install-new /boot/config/plugins/nut/libmodbus-3.1.10-x86_64-1usb.txz Nov 7 12:12:28 Tower root: plugin: checking: /boot/config/plugins/nut/nut-plugin-2023.11.06-x86_64-1.txz - MD5 Nov 7 12:12:28 Tower root: plugin: skipping: /boot/config/plugins/nut/nut-plugin-2023.11.06-x86_64-1.txz already exists Nov 7 12:12:28 Tower root: plugin: running: upgradepkg --install-new /boot/config/plugins/nut/nut-plugin-2023.11.06-x86_64-1.txz Nov 7 12:12:28 Tower root: plugin: running: anonymous Nov 7 12:12:33 Tower dummy-ups[9170]: Startup successful Nov 7 12:12:34 Tower upsd[9183]: listening on 0.0.0.0 port 3493 Nov 7 12:12:34 Tower upsd[9183]: Connected to UPS [ups]: dummy-ups-ups Nov 7 12:12:34 Tower dummy-ups[9170]: sock_connect: enabling asynchronous mode (auto) Nov 7 12:12:34 Tower upsd[9183]: Found 1 UPS defined in ups.conf Nov 7 12:12:34 Tower upsd[9184]: Startup successful Nov 7 12:12:34 Tower upsmon[9187]: Startup successful Nov 7 12:12:34 Tower upsd[9184]: User [email protected] logged into UPS [ups] Nov 7 12:12:34 Tower root: plugin: nut-dw.plg updated So you'll see the same SIGTERM but then the processes get started up again just fine... I'll test this some more with the auto update and will report back as soon as I know more 🙂

I would suggest to "Reset Config" and then set it up again as in your screenshot. Maybe there are some broken parts in your configuration that's causing the issue. You can see the configuration files at the end of the "NUT Settings" page.

OK that makes more sense in this context, it seems it's doing an actual unsupervised update/"auto update" to the plugin and not just checking if there's an update available. As part of the updating process NUT services are always stopped (so there are no file locks during updating). So that itself would explain the SIGTERM but after the update the services should be brought up again through the following lines: echo "Starting NUT services..." /etc/rc.d/rc.nut start Is there anything in the logs that would indicate it attempted or failed to bring up the services again? Maybe this is a permission issue that 'anonymous' (as in your log) is not able or allowed to bring up the services as opposed to a "manual update"? There are already libssl1 versions of older backends (namely release 2.8.0 / legacy 2.7.4) available and they should be visible on the Network UPS Tools Backend Switch. That is unless you're on a version that's not between 6.10 and 6.12.99, so on 6.13 you'd only see "default" - because I had no access to such a version yet and hence wasn't able to test anything like that. 🙂 P.S. Feel free to submit a PR, but I'll have to think about it and can't promise I'll eventually merge it. I'm always relatively conservative on the decision what's useless noise and what's useful diagnostic information to others (or the backend developers when issues are brought up through GitHub). NUT is a relatively talkative program by design as the backend developers also seem to share this approach. Alternatively one can, of course, always also set up their syslog services to filter or discard useless information.