NUT Package (2.8.1 and above)

ha11oga11o · Dec 28, 2023, 5:10 PM

I am really sorry! i Made typo mistake. Actually system is

2.7.2-RELEASE (amd64)
built on Fri Dec 8 21:55:00 CET 2023
FreeBSD 14.0-CURRENT

nut package 2.8.2

and error is still persists on this setup. This is latest log, and i found it online this morning.

Dec 27 18:42:48 	upsmon 	57881 	UPS RielloSEP2200 on line power
Dec 27 18:42:43 	upsmon 	57881 	UPS RielloSEP2200: on bypass (powered, not protecting)
Dec 27 18:42:43 	upsmon 	57881 	Communications with UPS RielloSEP2200 established
Dec 27 18:42:43 	upsd 	61706 	User local-monitor@127.0.0.1 logged into UPS [RielloSEP2200]
Dec 27 18:42:41 	upsd 	61706 	Connected to UPS [RielloSEP2200]: riello_usb-RielloSEP2200
Dec 27 18:42:41 	riello_usb 	67935 	Startup successful
Dec 27 18:42:39 	upsd 	61706 	Startup successful
Dec 27 18:42:39 	upsd 	61406 	Found 1 UPS defined in ups.conf
Dec 27 18:42:39 	upsd 	61406 	Can't connect to UPS [RielloSEP2200] (riello_usb-RielloSEP2200): No such file or directory
Dec 27 18:42:39 	upsd 	61406 	listening on ::1 port 3493
Dec 27 18:42:39 	upsd 	61406 	listening on 127.0.0.1 port 3493
Dec 27 18:42:38 	upsmon 	57881 	Communications with UPS RielloSEP2200 lost
Dec 27 18:42:38 	upsmon 	57881 	UPS [RielloSEP2200]: connect failed: Connection failure: Connection refused
Dec 27 18:42:38 	upsmon 	57329 	Startup successful
Dec 27 18:42:38 	riello_usb 	43008 	Signal 15: exiting
Dec 27 18:42:38 	upsd 	34960 	Signal 15: exiting
Dec 27 18:42:38 	upsd 	34960 	mainloop: Interrupted system call
Dec 27 18:42:38 	upsd 	34960 	User local-monitor@127.0.0.1 logged out from UPS [RielloSEP2200]
Dec 27 18:42:38 	upsmon 	33505 	Signal 15: exiting
Dec 27 18:42:37 	upsmon 	33505 	Poll UPS [RielloSEP2200] failed - Data stale
Dec 27 18:42:37 	riello_usb 	43008 	Communication with UPS is lost: status read failed!
Dec 27 18:42:35 	riello_usb 	43008 	Communication with UPS is lost: status read failed!
Dec 27 18:42:33 	riello_usb 	43008 	Communication with UPS is lost: status read failed!
Dec 27 18:42:32 	upsmon 	33505 	Poll UPS [RielloSEP2200] failed - Data stale
Dec 27 18:42:31 	riello_usb 	43008 	Communication with UPS is lost: status read failed!
Dec 27 18:42:29 	riello_usb 	43008 	Communication with UPS is lost: status read failed!
Dec 27 18:42:27 	upsmon 	33505 	Poll UPS [RielloSEP2200] failed - Data stale
Dec 27 18:42:27 	riello_usb 	43008 	Communication with UPS is lost: status read failed!
Dec 27 18:42:24 	riello_usb 	43008 	Communication with UPS is lost: status read failed!
Dec 27 18:42:22 	riello_usb 	43008 	Communication with UPS is lost: status read failed!
Dec 27 18:42:22 	upsmon 	33505 	Poll UPS [RielloSEP2200] failed - Data stale

Thanks and sorry again.

Speaking of the devil, just while i was writing this it lost connection.

Dec 28 12:24:12 	riello_usb 	24097 	Communication with UPS is lost: status read failed!
Dec 28 12:24:12 	upsmon 	8652 	Poll UPS [RielloSEP2200] failed - Data stale
Dec 28 12:24:10 	riello_usb 	24097 	Communication with UPS is lost: status read failed!
Dec 28 12:24:08 	riello_usb 	24097 	Communication with UPS is lost: status read failed!
Dec 28 12:24:07 	upsmon 	8652 	Poll UPS [RielloSEP2200] failed - Data stale
Dec 28 12:24:06 	riello_usb 	24097 	Communication with UPS is lost: status read failed!
Dec 28 12:24:04 	riello_usb 	24097 	Communication with UPS is lost: status read failed!
Dec 28 12:24:02 	riello_usb 	24097 	Communication with UPS is lost: status read failed!
Dec 28 12:24:02 	upsmon 	8652 	Poll UPS [RielloSEP2200] failed - Data stale
Dec 28 12:24:00 	riello_usb 	24097 	Communication with UPS is lost: status read failed!
Dec 28 12:23:58 	riello_usb 	24097 	Communication with UPS is lost: status read failed!
Dec 28 12:23:57 	upsmon 	8652 	Poll UPS [RielloSEP2200] failed - Data stale
Dec 28 12:23:56 	riello_usb 	24097 	Communication with UPS is lost: status read failed!

msurg · Dec 28, 2023, 3:34 PM

Hello,

With Pfsense 2.7.0 CE I could get UPS status with the following config.

UPS Type: Local USB

Driver: nutdrv_qx

Extra Arguments to drive:
port=auto
vendorid="0001"
productid="0000"
langid_fix=0x409
protocol="megatec"
subdriver="hunnox"
novendor
noscanlangid

UPS is Makelsan. Link below

https://www.makelsan.com.tr/en/ups/urundetay/lion-serisi-650---2200-va/index-500.html

After upgrading Pfsense to 2.7.2 I don't get UPS status. It says "Failed to retrieve status".

Nothing changed. Only upgraded from 2.7.0 CE to 2.7.2 CE.

Any help will be appreciated.

dennypage · Jan 13, 2024, 5:23 PM

@ha11oga11o Your first example appears to be an interface state change. You can see that NUT is explicitly being terminated (signal 15).

There is not enough information in your second example to say anything about.

There is a patch you may try to help with the interface state change:

--- nut.inc.org	2023-11-17 05:42:10.000000000 -0800
+++ 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";

Note that after applying the patch, you will need to go into UPS -> settings and press Save in order to activate the change..

ha11oga11o · Dec 28, 2023, 5:27 PM

@dennypage

signal 15 means that i stopped and restarted service. Only then i got it working for some time. Basically, updating box and nut did nothing for me regarding random disconnect.

Im not saying nut is bad, im just trying to figure it out whats going on with my USB link.

Tried 4-5 cables, and have 3 same UPSs... all doing same problem. I could link it via rs232 but, maybe someone cant, so im just reporting what kind of error i have.

Nut service is stable, not crashing and such, so patch is not needed? I think i troubles properly explaining my case. Sorry.

Can you, please tell me, what data you need from my box to have big picture here, and i will provide.

EDIT:

my log is actually flooded with this. I cant see where is beginning and where it is end. Log rotation is too often too.

Dec 28 17:42:21 	riello_usb 	99096 	Communication with UPS is lost: status read failed!
Dec 28 17:42:18 	riello_usb 	99096 	Communication with UPS is lost: status read failed!
Dec 28 17:42:17 	upsmon 	92937 	Poll UPS [RielloSEP2200] failed - Data stale
Dec 28 17:42:16 	riello_usb 	99096 	Communication with UPS is lost: status read failed!
Dec 28 17:42:14 	riello_usb 	99096 	Communication with UPS is lost: status read failed!
Dec 28 17:42:12 	riello_usb 	99096 	Communication with UPS is lost: status read failed!
Dec 28 17:42:12 	upsmon 	92937 	Poll UPS [RielloSEP2200] failed - Data stale
Dec 28 17:42:10 	riello_usb 	99096 	Communication with UPS is lost: status read failed!
Dec 28 17:42:08 	riello_usb 	99096 	Communication with UPS is lost: status read failed!
Dec 28 17:42:07 	upsmon 	92937 	Poll UPS [RielloSEP2200] failed - Data stale
Dec 28 17:42:06 	riello_usb 	99096 	Communication with UPS is lost: status read failed!
Dec 28 17:42:04 	riello_usb 	99096 	Communication with UPS is lost: status read failed!
Dec 28 17:42:02 	riello_usb 	99096 	Communication with UPS is lost: status read failed!
Dec 28 17:42:02 	upsmon 	92937 	Poll UPS [RielloSEP2200] failed - Data stale
Dec 28 17:42:00 	riello_usb 	99096 	Communication with UPS is lost: status read failed!
Dec 28 17:42:00 	sshguard 	18696 	Now monitoring attacks.
Dec 28 17:42:00 	sshguard 	54116 	Exiting on signal.
Dec 28 17:42:00 	newsyslog 	18014 	logfile turned over due to size>500K
Dec 28 17:42:00 	newsyslog 	18014 	logfile turned over due to size>500K
Dec 28 17:41:58 	riello_usb 	99096 	Communication with UPS is lost: status read failed!
Dec 28 17:41:57 	upsmon 	92937 	Poll UPS [RielloSEP2200] failed - Data stale
Dec 28 17:41:56 	riello_usb 	99096 	Communication with UPS is lost: status read failed!
Dec 28 17:41:54 	riello_usb 	99096 	Communication with UPS is lost: status read failed!
Dec 28 17:41:52 	riello_usb 	99096 	Communication with UPS is lost: status read failed!
Dec 28 17:41:52 	upsmon 	92937 	Poll UPS [RielloSEP2200] failed - Data stale
Dec 28 17:41:50 	riello_usb 	99096 	Communication with UPS is lost: status read failed!
Dec 28 17:41:48 	riello_usb 	99096 	Communication with UPS is lost: status read failed!
Dec 28 17:41:47 	upsmon 	92937 	Poll UPS [RielloSEP2200] failed - Data stale
Dec 28 17:41:46 	riello_usb 	99096 	Communication with UPS is lost: status read failed!
Dec 28 17:41:44 	riello_usb 	99096 	Communication with UPS is lost: status read failed!
Dec 28 17:41:42 	upsmon 	92937 	Poll UPS [RielloSEP2200] failed - Data stale

Thanks

dennypage · Dec 28, 2023, 5:24 PM

@msurg said in NUT Package (2.8.1 and above):

Driver: nutdrv_qx

Extra Arguments to drive:
port=auto
vendorid="0001"
productid="0000"
langid_fix=0x409
protocol="megatec"
subdriver="hunnox"
novendor
noscanlangid

The version of NUT has changed quite a bit. From 2.7.4 to 2.8.1+. It's a major revision of NUT itself.

Things to do:

Run usbconfig -v to confirm that the UPS is properly attached and recognized.
Look for error messages associated with your driver in the system log. Not error messages from upsd or upsmon, but the actual driver.
Remove everything from the Extra Arguments to driver and use auto detection.
Try the blazer_usb driver.

Beyond that, I would recommend soliciting advice on the networkupstools user mailing list.

pfpv · Dec 28, 2023, 7:02 PM

@dennypage said in NUT Package (2.8.1 and above):

For those of you that are on amd64 based systems (Intel or AMD), and are severely affected by the shutdown on calibration/self-test issue, attached are replacement versions of upsmon and usbhid-ups that you can use until the update is published.

When will the package be updated in the pfSense repository so it becomes updatable from the GUI? Do you have an approximate timeline?

pfpv · Dec 28, 2023, 7:23 PM

@dennypage said in NUT Package (2.8.1 and above):

I will point out one thing that you said that you may wish to reconsider. You indicate that the NAS is the most important thing to have a proper shutdown. I agree with this general sentiment. However, by running the NAS as the NUT primary, you are actually incurring higher risk for the NAS rather than less.

The NUT primary does not initiate a shutdown until all the associated secondaries have logged out of the primary. Assuming a default polling interval of 5 seconds, a pfSense or Linux system will take something on the order of 10-15 seconds before they log out, and another 30-90 seconds to complete a shutdown. This means that the NAS will not begin its shutdown until 10-15 seconds after the UPS declares a low battery. Depending upon configuration and current activity, a Synology usually takes over 2 minutes to complete a shutdown. If the UPS is off in calculating remaining runtime, you run the risk of exhausting the battery before the NAS has completed its shutdown.

If you reverse this situation and use pfSense or a Linux system as the primary, then the NAS will begin its shutdown within 5 seconds. Not only does this give a wider margin of safety for the NAS, it can give an increased margin of safety for the other systems as well. When the NAS shuts down, there is suddenly a lot less load on the UPS, which gives more time for the other systems to complete their shutdown even if the estimated remaining runtime was incorrect.

Thank you for your wise advice. I will follow it. I did not know that the primary waits for secondaries' logout.

Can you please advise me on how to setup pfSense primary with Synology secondary? If I chose UPS Type "Local USB" on pfSense will it serve as a NUT server? I suppose I need to define a user for Synology in upsd.users?

On Synology, do I select UPS type "Synology UPS server"? There are only 3 options: "USB UPS", "SNMP UPS" and "Synology UPS server". While not obvious, only the last option has some sense.

When does one use an "apcupsd" package in pfSense? The description indicates I should be using it since I have an APC UPS.

dennypage · Dec 28, 2023, 7:32 PM

@pfpv said in NUT Package (2.8.1 and above):

@dennypage said in NUT Package (2.8.1 and above):

For those of you that are on amd64 based systems (Intel or AMD), and are severely affected by the shutdown on calibration/self-test issue, attached are replacement versions of upsmon and usbhid-ups that you can use until the update is published.

When will the package be updated in the pfSense repository so it becomes updatable from the GUI? Do you have an approximate timeline?

PRs for the next version are in place, but I expect that the core devs are off this week so the PR will not be looked at until next week. Best guess, one to two weeks.

dennypage · Dec 28, 2023, 7:42 PM

@pfpv said in NUT Package (2.8.1 and above):

Can you please advise me on how to setup pfSense primary with Synology secondary? If I chose UPS Type "Local USB" on pfSense will it serve as a NUT server? I suppose I need to define a user for Synology in upsd.users?

See post #2 in this thread, Notes on remote access to NUT, in this thread for information on how to enable remote access to NUT. At the end of the post, there is a section Notes on Synology which has the name and password requirements for interoperation with NUT on Synology.

@pfpv said in NUT Package (2.8.1 and above):

On Synology, do I select UPS type "Synology UPS server"? There are only 3 options: "USB UPS", "SNMP UPS" and "Synology UPS server".

NUT is the UPS management system on Synology, though they disguise the fact that they are using it. You would select "Synology UPS server" as the type UPS type.

APCUPSD is an alternative to NUT for managing APC UPSs. It does not interoperate with other UPS types, and does not work with NUT on Synology.

ha11oga11o · Dec 29, 2023, 1:06 PM

Hello,

USB connection is totally unstable so i connected it on rs232 port. It works fine so far, but still it says "Status Alert: The UPS requires attention". In logs i cannot find what kind of attention it needs this time. For me all data looks fine. Batteries are ok. temperature is 26C. Is there any way to see on what error is nut referring its statement about attention?

heres latest log:

Dec 29 13:52:00 	sshguard 	2303 	Now monitoring attacks.
Dec 29 13:52:00 	sshguard 	35323 	Exiting on signal.
Dec 29 13:50:22 	upsmon 	59353 	UPS RielloSEP2200 on line power
Dec 29 13:50:17 	upsmon 	59353 	UPS RielloSEP2200: on bypass (powered, not protecting)
Dec 29 13:50:17 	upsmon 	59353 	Communications with UPS RielloSEP2200 established
Dec 29 13:50:16 	upsd 	60905 	Connected to UPS [RielloSEP2200]: riello_ser-RielloSEP2200
Dec 29 13:50:15 	riello_ser 	87467 	Startup successful
Dec 29 13:50:12 	upsmon 	59353 	Poll UPS [RielloSEP2200] failed - Driver not connected
Dec 29 13:50:07 	upsmon 	59353 	Poll UPS [RielloSEP2200] failed - Driver not connected
Dec 29 13:50:02 	upsmon 	59353 	UPS RielloSEP2200 is unavailable
Dec 29 13:50:02 	upsmon 	59353 	Poll UPS [RielloSEP2200] failed - Driver not connected
Dec 29 13:50:02 	upsd 	60905 	User local-monitor@127.0.0.1 logged into UPS [RielloSEP2200]
Dec 29 13:49:58 	upsd 	60905 	Startup successful
Dec 29 13:49:58 	upsd 	60830 	Found 1 UPS defined in ups.conf
Dec 29 13:49:58 	upsd 	60830 	Can't connect to UPS [RielloSEP2200] (riello_ser-RielloSEP2200): No such file or directory
Dec 29 13:49:58 	upsd 	60830 	listening on ::1 port 3493
Dec 29 13:49:58 	upsd 	60830 	listening on 127.0.0.1 port 3493
Dec 29 13:49:57 	upsmon 	59353 	Communications with UPS RielloSEP2200 lost
Dec 29 13:49:57 	upsmon 	59353 	UPS [RielloSEP2200]: connect failed: Connection failure: Connection refused
Dec 29 13:49:57 	upsmon 	59032 	Startup successful
Dec 29 13:49:57 	php-fpm 	37711 	/nut_settings.php: Starting service nut
Dec 29 13:49:57 	check_reload_status 	4706 	Syncing firewall
Dec 29 13:49:57 	php-fpm 	37711 	/nut_settings.php: Configuration Change: admin@192.168.1.210 (Local Database): Updated UPS settings
Dec 29 13:49:00 	php-cgi 	86948 	servicewatchdog_cron.php: Service Watchdog detected service nut stopped. Restarting nut (UPS monitoring daemon)
Dec 29 13:48:30 	riello_usb 	5395 	Signal 15: exiting
Dec 29 13:48:30 	upsd 	97144 	Signal 15: exiting
Dec 29 13:48:30 	upsd 	97144 	mainloop: Interrupted system call
Dec 29 13:48:30 	upsd 	97144 	User local-monitor@127.0.0.1 logged out from UPS [RielloSEP2200]
Dec 29 13:48:30 	upsmon 	95612 	Signal 15: exiting
Dec 29 13:48:30 	php-fpm 	2827 	/nut_settings.php: Stopping service nut

If that highlight is because of

Dec 29 13:50:22 	upsmon 	59353 	UPS RielloSEP2200 on line power
Dec 29 13:50:17 	upsmon 	59353 	UPS RielloSEP2200: on bypass (powered, not protecting)

That statement "not protecting" is not true. Its in ECO mode, so its not act like turbine. And works on demand relaying on its switching speed which works rather flawless.

login-to-view

Thank you in advance.

dennypage · Dec 29, 2023, 5:16 PM

@ha11oga11o said in NUT Package (2.8.1 and above):

It works fine so far, but still it says "Status Alert: The UPS requires attention".

Dec 29 13:50:17 upsmon 59353 UPS RielloSEP2200: on bypass (powered, not protecting)
That statement "not protecting" is not true. It's in ECO mode, so it's not act like turbine. And works on demand relaying on its switching speed which works rather flawless.

The UPS requires attention because NUT indicates that the UPS is on bypass, which would mean that power has bypassed the UPS protection circuits. This could be either a manual operation, or something automatic in response to an input power issue. Many UPSs have ECO modes, but this should not be reported as being in bypass mode.

Glancing at the manual for your unit, it appears to have a rich automatic bypass capability. Look carefully to see if your UPS is actually indicating that it is in bypass.

In the end, here are the possibilities as I see them:

The UPS is in bypass mode, and it is reporting correctly.
The UPS is incorrectly reporting that it is in bypass mode when it is not.
The UPS is not reporting that it is in bypass mode, but the driver is incorrectly declaring it to be.

If the issue is #2, then you will need to go to the UPS vendor.

If the issue is #3, then you will need to go to the networkupstools folk, or ask the vendor to go to them on your behalf.

ha11oga11o · Dec 29, 2023, 9:45 PM

@dennypage

I see what is problem here. As stated in manual:
"In order to optimize performance, in ECO mode, the load is normally powered by the bypass. If the mains goes out of the permitted tolerance range, the UPS switches to ON LINE operation. If the mains returns within the permitted tolerance range for at least five minutes, the UPS goes back to powering the load from the bypass."

And its exactly behaving like that. And thats fine i want it that way. It states "Summary status: On line, Bypass, Charging", its not sending in eg. "ECO mode", which should be unique status. It seems its mix of problem 1 and 2. Sadly i doubt manufacturer care to do anything about it. I just hope networkupstools folks will have time and way to fix this for this line of product. I think all SEPxxx have same function and could be affected with same issue. Also i can be that UPS itself not sending trigger about ECO mode and what it is actually means.

Many thnx for helping me understanding problem. That was really kind of you.

Cheers!

mcury · Jan 12, 2024, 6:06 PM

Overall, NUT is working perfectly for me.
But it seems that when a gateway bounces, NUT is being disconnected from the UPS and I get a few logs such as:

2024-01-12 14:57:34.000	upsmon[53646]:
upsmon[53646]: Communications with UPS ups lost
2024-01-12 14:57:34.000	upsmon[53646]:
upsmon[53646]: UPS [ups]: connect failed: Connection failure: Connection refused
2024-01-12 14:57:34.000	upsmon[52998]:
upsmon[52998]: Startup successful
2024-01-12 14:57:34.000	upsd[84388]:
upsd[84388]: Signal 15: exiting
2024-01-12 14:57:34.000	upsd[84388]:
upsd[84388]: mainloop: Interrupted system call
2024-01-12 14:57:34.000	upsd[84388]:
upsd[84388]: User local-monitor@127.0.0.1 logged out from UPS [ups]
2024-01-12 14:57:34.000	upsmon[54121]:
upsmon[54121]: Signal 15: exiting
2024-01-12 14:57:31.000	upsmon[54121]:
upsmon[54121]: Poll UPS [ups] failed - Driver not connected
2024-01-12 14:57:26.000	upsmon[54121]:
upsmon[54121]: Poll UPS [ups] failed - Driver not connected
2024-01-12 14:57:21.000	upsmon[54121]:
upsmon[54121]: Poll UPS [ups] failed - Driver not connected
2024-01-12 14:57:16.000	upsmon[54121]:
upsmon[54121]: Poll UPS [ups] failed - Driver not connected

Not sure but It really seems to be related to gateway/interface status changes.

To fix, I have to unplug the USB port from the UPS, reconnect it and then restart NUT in pfSense.

dennypage · Jan 13, 2024, 5:08 PM

@mcury said in NUT Package (2.8.1 and above):

But it seems that when a gateway bounces, NUT is being disconnected from the UPS

Look for a patch earlier in this thread, circa post 107 on December 28th.

[Sorry, permalinks don't appear to be functioning correctly in the forum.]

mcury · Jan 13, 2024, 5:17 PM

@dennypage said in NUT Package (2.8.1 and above):

@mcury said in NUT Package (2.8.1 and above):

But it seems that when a gateway bounces, NUT is being disconnected from the UPS

Look for a patch earlier in this thread, circa post 107 on December 28th.

[Sorry, permalinks don't appear to be functioning correctly in the forum.]

I applied it today, really thanks for that.
Not only applied the patch, but saved the config again and rebooted just to be safe.

Now I'm monitoring it

dennypage · Jan 13, 2024, 5:24 PM

@mcury said in NUT Package (2.8.1 and above):

Not only applied the patch, but saved the config again and rebooted just to be safe.

Yes, you do need to re-save the config. I edited the prior post and added a note indicating that.

NinthWave · Jan 13, 2024, 6:38 PM

@dennypage said in NUT Package (2.8.1 and above):

@pfpv said in NUT Package (2.8.1 and above):

I respectfully disagree about Synology. It's just a server that passes UPS messages. It's very stable, does it properly, has worked for years and I haven't seen any complaints. I chose to connect my UPS to Synology because in my opinion it is the most critical piece of equipment to be properly shut down, and it provides a NUT server for other equipment.

I don't disagree that there is a bug in NUT, and I will be looking at that shortly. That said...

I'm in my third generation of Synology equipment. Fifteen plus years. I have handled a number of support issues arising from Synology's NUT implementation, both mine and others. Their NUT implementation started out very straight forward, but over time it has evolved, becoming more and more specialized and complex. With DSM 7.2, it's gotten to the point that I don't consider it to be completely reliable, and view it as a primary of last resort.

I will point out one thing that you said that you may wish to reconsider. You indicate that the NAS is the most important thing to have a proper shutdown. I agree with this general sentiment. However, by running the NAS as the NUT primary, you are actually incurring higher risk for the NAS rather than less.

The NUT primary does not initiate a shutdown until all the associated secondaries have logged out of the primary. Assuming a default polling interval of 5 seconds, a pfSense or Linux system will take something on the order of 10-15 seconds before they log out, and another 30-90 seconds to complete a shutdown. This means that the NAS will not begin its shutdown until 10-15 seconds after the UPS declares a low battery. Depending upon configuration and current activity, a Synology usually takes over 2 minutes to complete a shutdown. If the UPS is off in calculating remaining runtime, you run the risk of exhausting the battery before the NAS has completed its shutdown.

If you reverse this situation and use pfSense or a Linux system as the primary, then the NAS will begin its shutdown within 5 seconds. Not only does this give a wider margin of safety for the NAS, it can give an increased margin of safety for the other systems as well. When the NAS shuts down, there is suddenly a lot less load on the UPS, which gives more time for the other systems to complete their shutdown even if the estimated remaining runtime was incorrect.

The relevant passage from upsmon.conf:
# Also, since the primary system stays up the longest, it suffers higher risks
# of ungraceful shutdown if the estimation of remaining runtime (or of the
# time it takes to shut down this system) was guessed wrong. By consequence,
# the "secondary" systems typically monitor the power environment state
# through the 'upsd' processes running on the remote (often "primary") systems
# and do not directly interact with an UPS (no local NUT drivers are running
# on the secondary systems). As such, secondaries typically shut down as
# soon as there is a sufficiently long power outage, or a low-battery alert
# from the UPS, or a loss of connection to the primary while the power was
# last known to be missing.
As a general rule, you want to have systems that represent the highest UPS load and/or longest shutdown time as secondaries, and a system that represents lower load and is fast to shut down as the primary.

I am not done reading the thread but this morning I had my second shutdown of pfSense. Same behavior as OP. I don't have a synology but a Proxmox machine hosting a Debian/Docker server.

At both events, everything stayed on except pfSense that shut down. no router, no LAN.

Going trough the rest of the thread.

dennypage · Jan 13, 2024, 8:39 PM

@NinthWave said in NUT Package (2.8.1 and above):

I am not done reading the thread but this morning I had my second shutdown of pfSense. Same behavior as OP. I don't have a synology but a Proxmox machine hosting a Debian/Docker server.

At both events, everything stayed on except pfSense that shut down. no router, no LAN.

Circa post 104 there are replacement executables that you may use until the next drop of NUT.

NinthWave · Jan 14, 2024, 3:09 AM

@dennypage said in NUT Package (2.8.1 and above):

@ha11oga11o said in NUT Package (2.8.1 and above):

With pfSense 2.7.0 and nut 2.8.2 i still have huge problems with Riello 2200.

Something is off with the version numbers here. pfSense-pkg-nut version 2.8.2 requires pfSense version 23.09/2.7.1 or above. Are you sure you are not running pfSense-pkg-nut version 2.8.0?

Edit: In the other thread you started, it appears that you haven't updated anything since Nov 10th. The pattern you are describing is characteristic of version 2.8.0. Did you go through any of the later posts in that thread? @Unoptanio indicates success with the Riello using version 2.8.2 of the pfSense-pkg-nut on pfsense version 2.7.1.

Thanks!

But where is one to copy these files ? I looked under /usr/bin and /usr/local/bin with no avail.

NinthWave · Jan 14, 2024, 2:59 AM

@dennypage said in NUT Package (2.8.1 and above):

@NinthWave said in NUT Package (2.8.1 and above):

I am not done reading the thread but this morning I had my second shutdown of pfSense. Same behavior as OP. I don't have a synology but a Proxmox machine hosting a Debian/Docker server.

At both events, everything stayed on except pfSense that shut down. no router, no LAN.

Circa post 104 there are replacement executables that you may use until the next drop of NUT.

Thanks. I did not see it at first.

Are you aware if there is a reason there are no subthreads is Netgate community.
Using Google, I typed "pfsense + the_push_message_when_pfsense_shutdown"
But if I were have been to look under "Nut Package (2.8.1 and above", I may not have read all the 122 messages.
A subthread for this issue would have been greatly appreciated.