NUT Package (2.8.1 and above)

[robertofelix]

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

administrative

Hey guys, I faced this very same issue twice, very annoying indeed. In my situation, I don't want a graceful shutdown for my pfSense.
I setup my box to come back when the power is back. With a graceful shutdown that wouldn't happen, correct me if I'm wrong.

Anyways, to avoid the NUT to shutdown my pfSense I did the following

Edited the file /usr/local/etc/nut/upsmon.conf removing the following lines

SHUTDOWNCMD "/sbin/shutdown -p +0"
POWERDOWNFLAG /etc/killpower

Then, you can just restart the service. I belive that does the job, but again, correct me if I'm wrong. I want NUT just to keep monitoring my UPS which is attached to my NAS. I don't want my pfSense goes down when I have a power failure.

[dennypage]

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

I don't want a graceful shutdown for my pfSense.
I setup my box to come back when the power is back. With a graceful shutdown that wouldn't happen, correct me if I'm wrong.

Yes, that is wrong. You have an incorrect BIOS setting. Change the Power setting from 'Last State' to 'Power On'.

[robertofelix]

@dennypage You're right. I changed that setting to 'Power On'.
Now, I believe if the NUT package misbehaves, the box will shut down, but it will power on back by itself, is that right?

[dennypage]

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

You're right. I changed that setting to 'Power On'.
Now, I believe if the NUT package misbehaves, the box will shut down, but it will power on back by itself, is that right?

The behavior of that bios setting is that the host will boot whenever power is applied to the box.

When NUT executes a shutdown, one of the very last things it does is to instruct the UPS to cut power after a sort delay. So following the return of mains, when the UPS brings power back on, the host will boot automatically.

[Gertjan]

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

Edited the file /usr/local/etc/nut/upsmon.conf removing the following lines

... and the next time nut (re) starts, that file, as the other 'nut' config files, will get re generated.
It's the core functionality of pfSense : one GUI to create one or more config file(s). From is one source, for every process, the needed config files are created and set up with the GUI settings.
If you want to have control yourself over the config files, go for a native FreeBSD, and install the needed packages manually, and now you've control, by editing all these files yourself

You probably want to know that this file exists : /usr/local/pkg/nut/nut.inc
Look what you find at 255

[whoami TM]

After migrating from a SG-4860 to a XG-7100 I think I'm starting to narrow down my disconnect issue.

I've even gone as far as replacing the battery in the UPS.

Sometime over the last few updates my APC UPS stopped reporting ONLINE/CHARGED and now reports ONLINE/DISCHARGING

I've tried setting
onlinedischarge_log_throttle_sec=num

Set the minimum frequency (in seconds) at which warnings would be emitted for an otherwise not handled OL+DISCHRG device status combination. Negative values disable sequentially repeated messages (when this state appears and persists).

in Extra Arguments to driver field for usbhid but it prevents NUT from connecting to the UPS.

[robertofelix]

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

You probably want to know that this file exists : /usr/local/pkg/nut/nut.inc

Yup, you're right, I rebooted and the config is back. I don't know if people using Opnsense are also facing this issue, maybe?
Anyways, good tip about that line 255. That helps.

[dennypage]

@whoami-TM said in NUT Package (2.8.1 and above):

I've tried setting
onlinedischarge_log_throttle_sec=num

I don't believe that is implemented yet. To my knowledge, that's planned for the next release of NUT.

[dem]

Speaking of onlinedischarge, we had several power flickers yesterday and with the latest NUT package I get a message like this for every flicker:

Dec 24 16:25:22 router usbhid-ups[31461]: ups_status_set: seems that UPS [CP1500PFCLCD] is in OL+DISCHRG state now. Is it calibrating or do you perhaps want to set 'onlinedischarge' option? Some UPS models (e.g. CyberPower UT series) emit OL+DISCHRG when offline.

There was also a brief outage which was detected correctly:

Dec 24 12:52:22 router upsmon[30759]: UPS CP1500PFCLCD on battery
Dec 24 12:52:27 router upsmon[30759]: UPS CP1500PFCLCD on line power

The onlinedischarge messages seem harmless so I guess I'll just ignore them.

[ha11oga11o]

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

Dec 27 18:33:38 	riello_usb 	43008 	Communication with UPS is lost: status read failed!
Dec 27 18:33:35 	riello_usb 	43008 	Communication with UPS is lost: status read failed!
Dec 27 18:33:34 	upsmon 	33505 	Poll UPS [RielloSEP2200] failed - Data stale
Dec 27 18:33:33 	riello_usb 	43008 	Communication with UPS is lost: status read failed!
Dec 27 18:33:31 	riello_usb 	43008 	Communication with UPS is lost: status read failed!
Dec 27 18:33:29 	riello_usb 	43008 	Communication with UPS is lost: status read failed!
Dec 27 18:33:29 	upsmon 	33505 	Poll UPS [RielloSEP2200] failed - Data stale
Dec 27 18:33:27 	riello_usb 	43008 	Communication with UPS is lost: status read failed!
Dec 27 18:33:25 	riello_usb 	43008 	Communication with UPS is lost: status read failed!
Dec 27 18:33:24 	upsmon 	33505 	Poll UPS [RielloSEP2200] failed - Data stale
Dec 27 18:33:23 	riello_usb 	43008 	Communication with UPS is lost: status read failed!
Dec 27 18:33:21 	riello_usb 	43008 	Communication with UPS is lost: status read failed!
Dec 27 18:33:19 	riello_usb 	43008 	Communication with UPS is lost: status read failed!
Dec 27 18:33:19 	upsmon 	33505 	Poll UPS [RielloSEP2200] failed - Data stale
Dec 27 18:33:17 	riello_usb 	43008 	Communication with UPS is lost: status read failed!
Dec 27 18:33:15 	riello_usb 	43008 	Communication with UPS is lost: status read failed!
Dec 27 18:33:14 	upsmon 	33505 	Poll UPS [RielloSEP2200] failed - Data stale
Dec 27 18:33:13 	riello_usb 	43008 	Communication with UPS is lost: status read failed!
Dec 27 18:33:11 	riello_usb 	43008 	Communication with UPS is lost: status read failed!
Dec 27 18:33:09 	riello_usb 	43008 	Communication with UPS is lost: status read failed!
Dec 27 18:33:09 	upsmon 	33505 	Poll UPS [RielloSEP2200] failed - Data stale
Dec 27 18:33:07 	riello_usb 	43008 	Communication with UPS is lost: status read failed! 

Only stopping and starting nut service brings it back for some time. Restart not helping. I check hardware, it works fine on windows machine.

Thnx

[dennypage]

@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.

[dennypage]

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.

Note that these files are for amd64 systems only. I do not have a build/test system for arm. Sorry!

upsmon.gz

usbhid-ups.gz

[ha11oga11o]

@dennypage

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]

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]

@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]

@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]

@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]

@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]

@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]

@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.