NUT Package (2.8.1 and above)
-
@dennypage Thanks for the clarification. However, the over-notification problem appears to be a NUT/pfSense issue and doesn't seem to have anything to do with OpenVPN specifically. I disabled my OpenVPN connections and am still able to get the the "Communications with UPS ups lost" / "Communications with UPS ups established" emails by simply opening WAN interface page, clicking Save without changing anything, and then clicking Apply Changes.
Did something change in NUT's monitoring/polling system between 2.7.x and 2.8.x? It seems like NUT is now detecting a 'process restart' as a 'UPS disconnect'.
-
@mlake said in NUT Package (2.8.1 and above):
I disabled my OpenVPN connections and am still able to get the the "Communications with UPS ups lost" / "Communications with UPS ups established" emails by simply opening WAN interface page, clicking Save without changing anything, and then clicking Apply Changes.
This is the same thing as above, however in this case you are restarting the WAN interface instead of the OpenVPN interface.
-
@mlake said in NUT Package (2.8.1 and above):
Did something change in NUT's monitoring/polling system between 2.7.x and 2.8.x? It seems like NUT is now detecting a 'process restart' as a 'UPS disconnect'.
Another item of note is that email notifications for non root processes (such as NUT) were broken in 23.05/2.7.0 which would have suppressed the emails. Pushover (and others) worked though.
-
@dennypage Curious - this may speak to the reason why I wasn't seeing the emails when a quick change happened in 23.05, but I certainly did get emails when I had a power outage.
For now, I'm going to disable the email notifications because they're not helpful and are just reporting false-positives.
It seems that when restarted by the system, there is a race condition and NUT should probably withhold sending notifications until the system has had time to bring interfaces back up.
Thanks for responding to these and at least clarifying that some of the underlying behavior is expected.
-
@mlake Do me a favor?
Try with this patch and let me know if it suppresses the problem when your OpenVPN connection flaps.
You will need to go into UPS -> settings and press Save in order to activate the change.
--- /usr/local/pkg/nut/nut.inc.org 2023-11-17 05:42:10.000000000 -0800 +++ /usr/local/pkg/nut/nut.inc 2023-12-05 15:20:38.575637000 -0800 @@ -82,14 +82,19 @@ $start .= "\n /usr/bin/killall -q -9 $driver"; } - /* Service status keys off upsmon, so start it first. */ - $start .= "\n /usr/local/sbin/upsmon"; if (isset($driver)) { $start .= "\n /usr/local/sbin/upsdrvctl start &"; - /* Since we are starting the driver in backgroud, give it a moment to start. */ - $start .= "\n sleep 1"; $start .= "\n /usr/local/sbin/upsd -u root"; + + /* + * Since we are starting the driver in backgroud, give + * the driver and upsd a moment to start. + */ + $start .= "\n sleep 1"; } + + /* NB: Service status keys off of upsmon. */ + $start .= "\n /usr/local/sbin/upsmon"; $start .= "\n return 0"; $stop = "echo stopping NUT"; -
@dennypage Wow, thank you! Got the patch applied (made a "nut.inc.org" copy and had to put "/usr" as the Base Directory to get it to take) and the results look promising. I've tried a few interface resets that normally cause the notifications and I've only gotten it to trigger once. Unplugging the UPS and plugging it back in works as expected. I'm going to let this sit for a few days and I'll check back in.
-
@mlake said in NUT Package (2.8.1 and above):
(made a "nut.inc.org" copy and had to put "/usr" as the Base Directory to get it to take) and the results look promising.
Use the patches GUI :
Give it a description, like the URL of this fprum thread.
No URL/Commit ID,
Paste the patch as fond above,
Path strip count : set to 1
Base dir = /
Auto apply : free of choice.
save, and the patch is now ready to be applied.
So Apply.
Restart the UPS service as indicated above. -
@Gertjan Ah thanks, yes! (First time applying a manual patch... now the UI makes more sense).
-
@dennypage The patch seems to have solved my Suricata restarting interfaces too. I applied the patch and restarted Suricata, which would normally generate 2 connection lost and one connect established messages when NUT restarted, but the messages were supressed. The sleep delays seem to have done the trick. Thanks a bunch!
-
Im having issues getting pfsense to conect to the NUT server on my Synology whilst that connection work on other servers on my system:
"ld-elf.so.1: Shared object "libssl.so.30" not found, required by "upsmon"
nut sysutils 2.8.2
PfSense Version 2.7.0-RELEASE (amd64). Installed clean, not upgradedSynology 192.168.2.3
"synoups.conf"ups_enabled="yes" ups_mode="usb" ups_safeshutdown="no" ups_acl="192.168.2.1|192.168.2.12||||""upsd.users"
[monuser] password = slaveHome Assistant connects to this and outputs ;
"domain": "nut", "title": "synology.home.lan:3493", "data": { "host": "synology.home.lan", "port": 3493, "username": "**REDACTED**", "password": "**REDACTED**"Home Assistant Status 192.168.2.12 (excert):
"status": { "battery.capacity": "9.00", "battery.charge": "100", "battery.charge.low": "20", "battery.charge.restart": "0", "battery.energysave": "no", "battery.protection": "yes"PfSense config 192.168.2.1
cat /usr/local/etc/nut/upsmon.conf MONITOR ups@192.168.2.3 1 monuser slave slaveLog output when started manually:
starting NUT ld-elf.so.1: Shared object "libssl.so.30" not found, required by "upsmon" -
@bashers46899
Looked up the error "shared object "libssl.so.30" not found" and can see it was possibly resoloved by an upgrade from 2.7.0 to 2.7.3.
I've done this, reinstalled the NUT package amd it all seems fine now:
-
@bashers46899 said in NUT Package (2.8.1 and above):
Im having issues getting pfsense to conect to the NUT server on my Synology whilst that connection work on other servers on my system:
"ld-elf.so.1: Shared object "libssl.so.30" not found, required by "upsmon"
nut sysutils 2.8.2
PfSense Version 2.7.0-RELEASE (amd64). Installed clean, not upgradedThe version of OpenSSL changed with 23.09/2.7.1. The error you experienced happens when a version of the package that is intended for 23.09/2.7.1 or above is installed on an older version of pfSense (23.05/2.7.0).
NUT 2.8.2 should not have been offered for installation with 23.05/2.7.0. That said, you are not the only person who has experienced this, so I think there is/was a hiccup related to the package repo.
EDIT: there is a note about resolving the package repo issue here.
-
@dennypage
NUT 2.8.1
PFSENSE 2.7.1Riello Sentinel Pro 2200 with USB cable
after 4 days of being connected the disconnection problems reoccur
only by restarting the service did it restart
various email notifications:
Notifications in this message: 3 ================================ 18:23:40 UPS Notification from xxx-pfSense.home.arpa - Sat, 09 Dec 2023 18:23:40 +0100 Communications with UPS SentinelPRO lost 18:23:44 UPS Notification from xxx-pfSense.home.arpa - Sat, 09 Dec 2023 18:23:44 +0100 Communications with UPS SentinelPRO lost 18:23:49 UPS Notification from xxx-pfSense.home.arpa - Sat, 09 Dec 2023 18:23:49 +0100 UPS SentinelPRO is unavailable -
@dennypage I haven’t had a single erroneous ‘connection lost’ notification in the last week, so I’d guess that your patch did the trick. Thank you!
-
I'll apologize in advance, but I need some help getting pointed in the right direction.
I have a APC Back-UPS Pro Gaming 1500VA UPS BGM1500B that was working fine in 23.09 on my SG-4860. SG-4860 died and migrated to a XG-7100 that was still on 2.4.4 when I received it. Netgate sent me 23.09.1 and I haven't been able to get my APC to stay connected for longer than 24hrs.
This makes it harder for me to trouble shoot since I've never had it working on this box.
I had to use the "user=root" in ups.conf to get it to show when i first connected the usb. I also tried adding the quirk with
bDeviceSubClass = 0x0000 bDeviceProtocol = 0x0000 bMaxPacketSize0 = 0x0040 idVendor = 0x051d idProduct = 0x0002 bcdDevice = 0x0106 iManufacturer = 0x0001 <retrieving string failed> iProduct = 0x0002 <retrieving string failed> iSerialNumber = 0x0003 <retrieving string failed> bNumConfigurations = 0x0001 usbconfig add_dev_quirk_vplh 0x051d 0x0002 0x0000 0xffff UQ_HID_IGNOREBut still cant get past 24hrs. The 2 USB 2.0 ports on the XG-7100 will only stay connected to the UPS for a few hours at most. The USB 3.0 port will give me about 24hrs.
I remember reading in the old post about something to do specifically for APC but not sure if that applies to this version of NUT.
Thanks
-
-
This post is deleted! -
@Unoptanio said in NUT Package (2.8.1 and above):
NUT 2.8.1
PFSENSE 2.7.1Riello Sentinel Pro 2200 with USB cable
NUT 2.8.2
PFSENSE 2.7.2Riello Sentinel Pro 2200 with USB cable
From December 9th to today December 17th it has no longer been disconnected.
In the meantime, however, I updated to pfsense 2.7.2 -
I have a UPS connected to my Synology NAS via USB port. Synology NAS acts as a UPS Server, which in turn is connected to the pfSense NUT service, 2.8.2, all on the same network. All is mostly working well with status displayed on both systems.
Recently, though, I had an automatic shutdown of my pfSense, which is good, but I want to have this automatic shutdown delayed by 10 minutes. I have ~1-2x/month a very brief power outage, only 1-2 seconds. It's enough to trigger the UPS and make me reset some clocks though!
Here are the pfsense logs implementing the shutdown process. Note, this was another brief power outage of a few seconds. This was not a long outage. How can I delay the pfSense shutdown process by 10 minutes, so the UPS recovers its normal operating status?
-
@BaseBallHat said in NUT Package (2.8.1 and above):
Recently, though, I had an automatic shutdown of my pfSense
I came here to post about the exact same problem. I have the same setup - an APC UPS connected to Synology that serves as a UPS server. I've had this setup for a couple of years without issues. I recently updated pfSense Plus to 23.09.1 and I guess this updated the nut package to 2.8.2.
Today my pfSense suddenly shut down. I got a message in Pushover "Auto logout and shutdown proceeding". I didn't understand what was going on as there was no power failure. I ran to the basement and everything was on except pfSense. The UPS's fan was on, so I guess the UPS did a self-test. I noticed before that my Back-UPS RS 1500G and other similar units do self-tests from time to time and those that have fans turn them on for some time. This never caused a problem.
I logged into Synology and there was no sign of any UPS event in the logs or anywhere, it was actually happily doing data scrubbing (and successfully finished it later). I went to check pfSense's logs and found what you found:
UPS ups@192.168.0.61: administratively OFF or asleepAnd later:
Executing automatic power-fail shutdown Auto logout and shutdown proceeding halt by root:I've never seen that "administratively OFF or asleep" message before but according to man for upsmon it's a valid message. But why does it cause shutdown? Logically it shouldn't. If the UPS is off it's too late to shutdown. Also, I wonder why Synology doesn't see such messages or maybe it ignores them.
If there are any developers here, please look into it. It started happening since nut was updated to 2.8.2. I think I would have to disable it until this is looked into. This message shouldn't cause shutdown.
P.S. Found posts about this issue with unraid: https://forums.unraid.net/topic/60217-plugin-nut-v2-network-ups-tools/page/40/
See the quoted post. Seems to be version-related. When rolled back to 2.8.0 the issue goes away. Is there any way to roll back to the previous version of NUT? It seems this may not be easy as there is something about SSL certificates and the recent update of OpenSSL. Can anyone advise?
