tallguydirk

Background:Unraid includes apcupsd by default, and /etc/logrotate.d/apcupsd is configured to rotate /var/log/apcupsd.events weekly on Sundays at 4:40am via cron. This rotation triggers a restart of apcupsd, which results in a brief "Communications with UPS lost" message in the syslog. Jun 22 04:40:02 Tower rc.apcupsd: Restarting APC-UPS Power Management... Jun 22 04:40:03 Tower rc.apcupsd: Stopping APC-UPS Power Management... Jun 22 04:40:03 Tower apcupsd[3181830]: apcupsd exiting, signal 15 Jun 22 04:40:03 Tower rc.apcupsd: APC-UPS Power Management... Failed. Jun 22 04:40:03 Tower apcupsd[3181830]: Communications with UPS lost. Jun 22 04:40:03 Tower kernel: usb 1-5: reset full-speed USB device number 4 using xhci_hcd Jun 22 04:40:03 Tower apcupsd[3181830]: apcupsd shutdown succeeded Jun 22 04:40:04 Tower rc.apcupsd: Starting APC-UPS Power Management... Jun 22 04:40:04 Tower rc.apcupsd: APC-UPS Power Management... Started. Jun 22 04:40:04 Tower apcupsd[2135584]: apcupsd 3.14.14 (31 May 2016) slackware startup succeeded Jun 22 04:40:04 Tower apcupsd[2135584]: NIS server startup succeeded Problem:Unraid then generates a critical alert notification, even though this is a normal, expected event caused by the built-in log rotation. This is a confusing and unnecessary alert for users who have not actually experienced a UPS failure. Users expect to be alerted only for real UPS communication failures. False positives reduce trust in the alerting system and cause unnecessary concern. I personally have spent many hours trying to figure out what is causing this and whether I need to worry about it and I've come across a bunch of threads with other users inquiring about the same thing. Unraid Notification: TIME EVENT SUBJECT DESCRIPTION IMPORTANCE 29-06-2025 04:40 Unraid Server Alert UPS Alert Warning communications lost with UPS XCESSUPS alert 22-06-2025 04:40 Unraid Server Alert UPS Alert Warning communications lost with UPS XCESSUPS alert Feature Request:Please suppress the "Communication with UPS lost" notification when the event occurs at the known scheduled restart time (e.g., Sunday 4:40am daily) caused by logrotate. This could be achieved by: - Temporarily suppressing the commfailure event in apccontrol if it occurs in a small window around 4:40am - Or modifying the notification system to ignore this specific expected logrotate-triggered restart Thank you for considering!

I am also impacted by this Mover Tuning Plugin bug. Caused my cache to fill up and made a mess.

Decided to create a bug report so if anyone has input please post there instead...mods feel free to delete this.

I decided to try going from 6.12.10 to 6.12.11 and was able to do so and get an IP automatically. Then I went from 6.12.11 to 6.12.13 and again was able to get an IP automatically. Then I went from 6.12.13 to 6.12.14 and have the same problem described in this thread. So the problem is definitely something with 6.12.14.

Appreciate the response/suggestion @JorgeB! I am not sure how to do that but I will look into it. I noticed in 6.10.12 the same cdc_ether device get registered to usb0: while in 6.10.14 it gets registered to eth0: Seems like something has changed with the kernel or drivers that results in the same device being recognized/registered differently in 6.10.12 vs 6.10.14. Does this seem like something that I should file a bug report for so that an official fix could maybe be implemented?

Coming from 6.12.10 - everything was working fine, but after upgrading to 6.12.14 I lost network. No hardware changes. My AsRockRack E3C246D4U motherboard has 2 onboard LAN ethernet NICs which are both disabled in BIOS. I have a Mellanox ConnectX-3 EN (MCX311A-XCAT) 10Gbe PCIe NIC installed (single port) which is what unraid should be using for network. However, in 6.12.14, Unraid has assigned eth0 to some USB NIC device I've never heard of called "CDC Ethernet Device" while it assigns my Mellanox NIC to eth1. (Screenshot from IPMI KVM below) In the previous OS version (6.12.10), the Mellanox 10Gbe NIC is automatically assigned to eth0 and the virtual USB NIC device is disabled: There is definitely no physical USB ethernet adapters connected to the server. Maybe this is a red herring, but my best guess is that this is a virtual device that is there for IPMI KVM redirection purposes?? I found a support thread from another user mentioning the same type of "cdc_ether" device and for them it ended up being related to their Dell iDRAC (Dell's IPMI implementation) "OS TO IDRAC PASS THROUGH" feature, which they disabled and that fixed their problem. I have looked all through the BMC Settings in the BIOS as well as in AsRockRack's HTML5 IPMI KVM tool and I can't find anything relating to USB NIC pass-through (there is pass-through settings but only for virtual floppy/optical/harddisk). There is no network-rules.cfg file in /boot/config and therefore no Interface Rules section in Network Settings in the GUI so I am unable to manually assign the Mellanox 10Gbe NIC to eth0. I tried to rename /boot/config/network.cfg and reboot, but this didn't fix it. In Network Settings, I tried to disable bonding and bridging on the eth0 USB NIC and reboot but that didn't work either. I then rolled back to 6.12.10 and everything was working again. I have attached Diagnostics. Appreciate any assistance! tower-diagnostics-20241209-1158.zip

agree!!

did you ever figure this out? I'm having similar problem except I didn't add a new NIC. I just upgraded from 6.12.10 to 6.12.14 and after rebooting to apply the update I lost network...

I see there's a new BMC version 1.90.00 released 12/4/2024. For description it just says "update sensors reading", wonder what specifically that means?? Has anyone tried it yet?

I just opened terminal and typed "sensors-detect"

Think I figured out a workaround. So I tried running sensors-detect in terminal and the final output listed the name of the drivers associated with each adapter: Now follows a summary of the probes I have just done. Just press ENTER to continue: Driver `coretemp': * Chip `Intel digital thermal sensor' (confidence: 9) Driver `to-be-written': * ISA bus, address 0xca2 Chip `IPMI BMC KCS' (confidence: 8) Driver `jc42': * Bus `SMBus I801 adapter at efa0' Busdriver `i2c_i801', I2C address 0x18 Chip `IDT TSE2004' (confidence: 5) * Bus `SMBus I801 adapter at efa0' Busdriver `i2c_i801', I2C address 0x1a Chip `IDT TSE2004' (confidence: 5) Driver `nct6775': * ISA bus, address 0x290 Chip `Nuvoton NCT6791D Super IO Sensors' (confidence: 9) Note: there is no driver for IPMI BMC KCS yet. Check https://hwmon.wiki.kernel.org/device_support_status for updates. Do you want to generate /etc/sysconfig/lm_sensors? (yes/NO): yes Copy prog/init/lm_sensors.init to /etc/init.d/lm_sensors for initialization at boot time. You should now start the lm_sensors service to load the required kernel modules. Unloading i2c-dev... OK Then I went into the plugin and in the 'Available drivers' field I typed 'jc42' > save > load drivers. This gave me 2 new sensors that weren't showing before and all my existing sensors remained. Then I tried 'coretemp' > save > load drivers. This gave me all of the coretemp sensors that I was missing. This is what I see now:

Yes I tried unloading and reloading and even uninstalling the plugin and re-installing, same results every time.

So I don't have the same sensors available...any idea why? E3C246D4U BIOS L2.34 BMC 1.80.00 ME Firmware Version 5.1.4.208 UNRAID 6.9.2 Dynamix System Temp Plugin v2020.06.20 I clicked detect > it sees 'coretemp nct6775' > save > load drivers > and I only see these options:

Awesome plugin! Thanks a lot for making it!! Is it possible to display more than 4 sensors in the footer? I have 9 different sensors that I'd like to include and plenty of real estate in the footer to fit them all.