Beta test of new NUT UPS package

dennypage

Glad it worked for you justmie. No log files necessary. Thank you again for your help.

Starrbuck

I found a strange bug. If I call Services >> UPS, it brings up https://192.168.1.1/nut_status.php properly. However, if I go to Services >> Snort, and then to Services >> UPS, it tries to call https://192.168.1.1/snort/nut_status.php.

dennypage

Thanks Starrbuck. I've committed a change that addresses this. Not sure how long it will take to come available.

Starrbuck

No hurry. It freaked me out for a bit until I figured out I was causing it by going to Snort first. ;)

dennypage

I'm not sure how long the release will take to go through the system, so I sent out a beta4 with the url fix. This should be the same as the pending release except for the version number. If you come across any other issues, please do let me know. Again, thank you for your help!

Starrbuck

Sure thing, glad to help.

w0w

I can report that all is working.
But I want report some strange issue, if you are just updating your previous beta then NUT service refuses to start automatically, widget just reports that UPS need attention and you must reboot or wait while it reconnects.

Jul 28 19:29:06 upsd 57399 - I've manually pushed start service button on UPS page


Jul 28 19:29:16 	upsmon 	58301 	Communications with UPS SMK-1000A established
Jul 28 19:29:15 	upsd 	57956 	Connected to UPS [SMK-1000A]: snmp-ups-SMK-1000A
Jul 28 19:29:13 	snmp-ups 	59689 	Startup successful
Jul 28 19:29:11 	upsmon 	58301 	UPS SMK-1000A is unavailable
Jul 28 19:29:11 	upsmon 	58301 	Poll UPS [SMK-1000A] failed - Driver not connected
Jul 28 19:29:06 	upsmon 	58301 	Communications with UPS SMK-1000A lost
Jul 28 19:29:06 	upsmon 	58301 	Poll UPS [SMK-1000A] failed - Driver not connected
Jul 28 19:29:06 	upsd 	57956 	User monuser@::1 logged into UPS [SMK-1000A]
Jul 28 19:29:06 	upsmon 	58073 	Startup successful
Jul 28 19:29:06 	upsd 	57956 	Startup successful
Jul 28 19:29:06 	upsd 	57399 	Can't connect to UPS [SMK-1000A] (snmp-ups-SMK-1000A): No such file or directory
Jul 28 19:29:06 	upsd 	57399 	listening on 127.0.0.1 port 3493
Jul 28 19:29:06 	upsd 	57399 	listening on ::1 port 3493
Jul 28 19:29:06 	upsd 	57399 	upsd.conf: invalid directive maxage = 25
Jul 28 19:27:52 	pkg 		pfSense-pkg-nut-2.7.4b4 installed
Jul 28 19:27:52 	php 		/etc/rc.packages: Successfully installed package: nut.
Jul 28 19:27:52 	check_reload_status 		Syncing firewall
Jul 28 19:27:51 	upsmon 	27988 	Communications with UPS SMK-1000A lost
Jul 28 19:27:51 	upsmon 	27988 	Poll UPS [SMK-1000A] failed - Driver not connected
Jul 28 19:27:51 	upsd 	27378 	User monuser@::1 logged into UPS [SMK-1000A]
Jul 28 19:27:51 	upsmon 	27815 	Startup successful
Jul 28 19:27:51 	upsd 	27378 	Startup successful
Jul 28 19:27:51 	upsd 	26835 	Can't connect to UPS [SMK-1000A] (snmp-ups-SMK-1000A): No such file or directory
Jul 28 19:27:51 	upsd 	26835 	listening on 127.0.0.1 port 3493
Jul 28 19:27:51 	upsd 	26835 	listening on ::1 port 3493
Jul 28 19:27:51 	upsd 	26835 	upsd.conf: invalid directive maxage = 25
Jul 28 19:27:51 	php 		/etc/rc.packages: Starting service nut
Jul 28 19:27:51 	snmp-ups 	86120 	Signal 15: exiting
Jul 28 19:27:51 	upsd 	61866 	Signal 15: exiting
Jul 28 19:27:51 	upsd 	61866 	mainloop: Interrupted system call
Jul 28 19:27:51 	upsd 	61866 	User monuser@::1 logged out from UPS [SMK-1000A]
Jul 28 19:27:51 	upsmon 	62862 	Signal 15: exiting
Jul 28 19:27:51 	php 		/etc/rc.packages: Stopping service nut
Jul 28 19:27:51 	check_reload_status 		Syncing firewall
Jul 28 19:27:51 	php 		/etc/rc.packages: Beginning package installation for nut .

Don't look at "maxage = 25" it's already fixed ;)

Also when I push restart service it restarts and "UPS Status" shows me same alert "Status Alert: The UPS requires attention", if I just hit refresh button in browser — everything coming back to normal state.

Sample log after pushing restart service:


Jul 28 19:47:35 	upsmon 	90347 	Communications with UPS SMK-1000A established
Jul 28 19:47:34 	upsd 	89700 	Connected to UPS [SMK-1000A]: snmp-ups-SMK-1000A
Jul 28 19:47:32 	snmp-ups 	14241 	Startup successful
Jul 28 19:47:30 	upsmon 	90347 	UPS SMK-1000A is unavailable
Jul 28 19:47:30 	upsmon 	90347 	Poll UPS [SMK-1000A] failed - Driver not connected
Jul 28 19:47:25 	upsmon 	90347 	Communications with UPS SMK-1000A lost
Jul 28 19:47:25 	upsmon 	90347 	Poll UPS [SMK-1000A] failed - Driver not connected
Jul 28 19:47:25 	upsd 	89700 	User monuser@::1 logged into UPS [SMK-1000A]
Jul 28 19:47:25 	upsmon 	90280 	Startup successful
Jul 28 19:47:25 	upsd 	89700 	Startup successful
Jul 28 19:47:25 	upsd 	88694 	Can't connect to UPS [SMK-1000A] (snmp-ups-SMK-1000A): No such file or directory
Jul 28 19:47:25 	upsd 	88694 	listening on 127.0.0.1 port 3493
Jul 28 19:47:25 	upsd 	88694 	listening on ::1 port 3493
Jul 28 19:47:25 	snmp-ups 	23316 	Signal 15: exiting
Jul 28 19:47:25 	upsd 	11392 	Signal 15: exiting
Jul 28 19:47:25 	upsd 	11392 	mainloop: Interrupted system call
Jul 28 19:47:25 	upsmon 	11755 	upsmon parent: read
Jul 28 19:47:25 	upsd 	11392 	User monuser@::1 logged out from UPS [SMK-1000A]
Jul 28 19:47:25 	upsmon 	11893 	Signal 15: exiting

Am I missing something or my configuration is wrong elsewhere?

I have attached one.

conf_nut.jpg_thumb

dennypage

The service being stopped on update is expected. The package install is being done outside of pfSense and there is nothing which calls for a start the service after.

I'll have a look at the other issue shortly.

dennypage

w0w, can you check something for me please?

Edit /usr/local/etc/rc.d/nut.sh and remove the ampersand from the end of the line where the driver is started:

/usr/local/sbin/upsdrvctl start

Then perform the service restart test. Thanks.

w0w

It does not change anything visually on Services/UPS/Status — it shows "Status Alert: The UPS requires attention". But log looks much better.


Jul 29 18:04:30 	upsd 	76451 	User monuser@::1 logged into UPS [SMK-1000A]
Jul 29 18:04:30 	upsmon 	76948 	Startup successful
Jul 29 18:04:30 	upsd 	76451 	Startup successful
Jul 29 18:04:30 	upsd 	76213 	Connected to UPS [SMK-1000A]: snmp-ups-SMK-1000A
Jul 29 18:04:30 	upsd 	76213 	listening on 127.0.0.1 port 3493
Jul 29 18:04:30 	upsd 	76213 	listening on ::1 port 3493
Jul 29 18:04:30 	snmp-ups 	76099 	Startup successful
Jul 29 18:04:23 	snmp-ups 	87584 	Signal 15: exiting
Jul 29 18:04:23 	upsd 	88014 	Signal 15: exiting
Jul 29 18:04:23 	upsd 	88014 	mainloop: Interrupted system call
Jul 29 18:04:23 	upsd 	88014 	User monuser@::1 logged out from UPS [SMK-1000A]
Jul 29 18:04:23 	upsmon 	88636 	Signal 15: exiting

Should we call Services/UPS/Status page refresh with some delay or use some flag memory that /usr/local/etc/rc.d/nut.sh have done it's job already?

DownloadDeviant

I'm not testing this but was hoping I could add some food for thought. Just speaking from my personal experience from running about 5 different pfSense routers for myself, my small business and a family member's small biz. I've used NUT and my typical setup is to have it remotely access the UPS connected directly to my Synology and/or FreeNAS devices. Obviously, because I'm dealing with small spaces and cannot have a dedicated UPS for every device.

My biggest headache has been when things go bad. Example - A pfSense router goes whacky and a fresh install then restore from backup config has to be performed. Typically, this is simple enough. However, I've always had trouble with NUT causing odd behavior with the recovery. I've had to manually edit the config file and remove all traces of NUT content. For the record, I've learned to create backup configs that do not include package data

I'd like to see this new version play nice on recovery if a config does happen to include package data…if possible.

Also, I'm very excited to see a new version and continued development of this package! Thanks DennyPage!

dennypage

Yea, that makes sense. Theres a bit of a catch-22 as the async startup for the driver is required to support the use of startup retry (maxretry/retrydelay) in ups.conf. It's taking a long time for the initial connect to the SNMP UPS.

Starrbuck

Beta 4 appears to have the same problem with Snort.

dennypage

Can you confirm the checksum on the following files please?

32332 22 /usr/local/www/nut_settings.php
14138 5 /usr/local/www/nut_status.php
47031 3 /usr/local/pkg/nut.xml
3633 12 /usr/local/pkg/nut/nut.inc

@Starrbuck:

Beta 4 appears to have the same problem with Snort.

Starrbuck

I uninstalled and reinstalled the package and it's ok now.

dennypage

Kinda figured that would do it. Thanks for confirming.

@Starrbuck:

I uninstalled and reinstalled the package and it's ok now.

w0w

This modification works for me.


$status = nut_ups_status();
if ($status['_alert']) {
	sleep(10);
	$status = nut_ups_status();
		if ($status['_alert']) {
		print_info_box("Status Alert: The UPS requires attention", "alert-danger");
}
}

The other issue I have — head.inc does not show restart service button anymore after successful restart, but if I unplug cable from SNMP card then it shows.

some_bug.jpg_thumb

w0w


$status = nut_ups_status();
if ($status['_alert']) {
	sleep(10);
}

$pgtitle = array(gettext("Services"), gettext("UPS"), gettext("Status"));
include("head.inc");
$tab_array = array();
$tab_array[] = array(gettext("UPS Status"), true, "/nut_status.php");
$tab_array[] = array(gettext("UPS Settings"), false, "/nut_settings.php");
display_top_tabs($tab_array);

$status = nut_ups_status();
		if ($status['_alert']) {
		print_info_box("Status Alert: The UPS requires attention", "alert-danger");
}

This way both problems fixed, with buttons and wait for service be ready on page load.

dennypage

Yea, there isn't much ill that a 10 second sleep doesn't fix. However I don't think I can introduce a 10 second sleep in the UX. It creates a delay in communicating the error condition for local UPSs.

w0w

@dennypage:

Yea, there isn't much ill that a 10 second sleep doesn't fix. However I don't think I can introduce a 10 second sleep in the UX. It creates a delay in communicating the error condition for local UPSs.

Sleep activated only if first $status query return '_alert', else NO DELAY applied. In normal condition if I understand your
nut.inc correctly this never should return '_alert' if connection is OK, it does not matter local or remote connection established.