-
Failed to install nut on my SG-3100 today due to net-snmp can't make temp file.
>>> Installing pfSense-pkg-nut... Updating pfSense-core repository catalogue... pfSense-core repository is up to date. Updating pfSense repository catalogue... pfSense repository is up to date. All repositories are up to date. Checking integrity... done (0 conflicting) The following 4 package(s) will be affected (of 0 checked): New packages to be INSTALLED: pfSense-pkg-nut: 2.7.4_7 [pfSense] nut: 2.7.4_13 [pfSense] neon: 0.30.2_4 [pfSense] net-snmp: 5.7.3_20,1 [pfSense] Number of packages to be installed: 4 The process will require 15 MiB more space. [1/4] Installing neon-0.30.2_4... [1/4] Extracting neon-0.30.2_4: .......... done [2/4] Installing net-snmp-5.7.3_20,1... [2/4] Extracting net-snmp-5.7.3_20,1: ...... pkg-static: Fail to create temporary file: /usr/local/lib/perl5/site_perl/mach/5.30/.SNMP.pm.DbwkOhQlQnQU:Input/output error [2/4] Extracting net-snmp-5.7.3_20,1... done Failed -
@sauce That looks like a generic package install problem, failing during install of net-snmp. You might re-try the install, perhaps following a reboot, and if it fails again follow up in the general pfSense packages forum.
-
@dennypage rebooting pfsense fix the installation of nut . Thank you for your help.
-
I'm having a bit of a problem with nut and pfSense.
I want to have pfSense shut down when low battery is at 30%. I tried at the default 20% (Eaton 5px) and I found it just did not leave enough time for pfSense to gracefully shut down.
I have configured nut as per below:
However, in my logs I get the error "dstate_setflags: base variable (battery.charge.low) is immutable". It is literally flooding my system logs.
Am I doing something wrong? Nut seems to ignore the ignorelb command and is still waiting until low battery gets to 20% (as reported by the ups).
I have also placed the below arguments in the ups.conf section to no avail. However, there were no error messages in the system logs.
community = private
ignorelb
override.battery.charge.low = 30I'm guessing I am doing something wrong but can't work it out. If it helps I am running an Eaton 5px with network-ms card
-
@Sir_SSV said in NUT package:
20 % - it just did not leave enough time for pfSense to gracefully shut down.
pfSense shuts down relatively fast.
"20 %" should leave you with 30 seconds or so, probably far more.
If non, the battery isn't in good shape. Or the UPS overloaded. Which decreases battery life / shape.I advise you to check out the NUT support forum.
-
@Sir_SSV Few quick comments
The "ignorelb" option literally means that you want to ignore a low battery condition signaled by the UPS. Unless your UPS sends a low battery indication immediately upon going to battery, this probably isn't something you want.
battery.charge.low is a value managed in the UPS. You are trying to set it, and don't have SNMP privs to do so. This probably isn't something you want either.
SNMP is polled at 30 seconds. This means there is an up to 30 second delay before nut knows it is on battery, and up to 30 seconds before nut knows that the battery is low.
In general, if you want to shut down sooner it's better to look at runtime remaining than battery charge.
-
@Gertjan said in NUT package:
@Sir_SSV said in NUT package:
20 % - it just did not leave enough time for pfSense to gracefully shut down.
pfSense shuts down relatively fast.
"20 %" should leave you with 30 seconds or so, probably far more.
If non, the battery isn't in good shape. Or the UPS overloaded. Which decreases battery life / shape.I advise you to check out the NUT support forum.
The ups is new, only had it for approx 1 month. It is not overloaded, have pfSense, freenas and a couple unifi switches.
@dennypage said in NUT package:
@Sir_SSV Few quick comments
The "ignorelb" option literally means that you want to ignore a low battery condition signaled by the UPS. Unless your UPS sends a low battery indication immediately upon going to battery, this probably isn't something you want.
battery.charge.low is a value managed in the UPS. You are trying to set it, and don't have SNMP privs to do so. This probably isn't something you want either.
SNMP is polled at 30 seconds. This means there is an up to 30 second delay before nut knows it is on battery, and up to 30 seconds before nut knows that the battery is low.
In general, if you want to shut down sooner it's better to look at runtime remaining than battery charge.
Thanks. Should I set the default polling time to a lower value?
How would I go about setting a runtime remaining configuration in nut?
-
@Sir_SSV said in NUT package:
Should I set the default polling time to a lower value?
How would I go about setting a runtime remaining configuration in nut?
As to the NUT config, it all depends upon how much runtime the UPS has in general, and how much runtime is remaining when the UPS signals a low battery situation. If the UPS has 3 or more minutes of runtime when entering low battery, I would simply let the UPS handle things. If it has less, you may want to shorten the pollfreq.
Given that you have a snmp management card, you likely have a good deal of configuration available in the UPS to control when low battery state is entered. The UPS is generally a better place to drive decisions than in the NUT configuration.
-
I recall my Eaton 5PX throw OB (on battery) and LB (low battery) at the same time, even with a large runtime remaining. In your UPS configuration you can configure the shutdown timers as Denny mentioned. Heres my 5px shutdown parameters.
If at 20% your UPS is failing to shutdown pfSense its likely your batteries are toast. Even new UPS can sit on shelves for sometime so worth testing before putting into production use.
-
@q54e3w said in NUT package:
I recall my Eaton 5PX throw OB (on battery) and LB (low battery) at the same time, even with a large runtime remaining. In your UPS configuration you can configure the shutdown timers as Denny mentioned. Heres my 5px shutdown parameters.
If at 20% your UPS is failing to shutdown pfSense its likely your batteries are toast. Even new UPS can sit on shelves for sometime so worth testing before putting into production use.
Thank you for the screen shot.
Under on battery, the values of 1800 seconds and 20% does that mean both of those values have to be met before the ups Initiated a shuts down?
If I wanted pfSense to shut down at 30% battery, would I pull the mains and see time remaining at 30% and input that value in to remaining time and shut down duration?
-
@Sir_SSV Been quite some time since I set this up so memory may be fuzzy but i recall its a 'OR' not 'AND'. You could stick 30% in percentage field and a small number in the time and it should shutdown (or flag LB & OB) at 30%.
Set it to 95% or something to test with to save running batteries up and down.EDIT: I just checked the manual and TL;DR
The first shutdown criteria initiates the restart of the shutdown sequence.
- If remaining time is under (0 to 99999 seconds, 180 by default) is the minimum remaining backup time
from which the shutdown sequence is launched. - If battery capacity is under (0 to 100%); this value cannot be less than that of the UPS and is the
minimum remaining battery capacity level from which the shutdown sequence is launched. - Shutdown after (0 to 99999 minutes, not validated by default) is the operating time in minutes left for
users after a switch to backup before starting the shutdown sequence. - Shutdown duration (120 seconds by default) is the time required for complete shutdown of systems
when a switch to backup time is long enough to trigger the shutdown sequences. It is calculated
automatically at the maximum of Shutdown duration of subscribed clients but can be modified in the
Advanced mode. - If battery capacity exceeds Minimum battery level to reach before restarting the UPS after utility
restoration
- If remaining time is under (0 to 99999 seconds, 180 by default) is the minimum remaining backup time
-
@q54e3w said in NUT package:
@Sir_SSV Been quite some time since I set this up so memory may be fuzzy but i recall its a 'OR' not 'AND'. You could stick 30% in percentage field and a small number in the time and it should shutdown (or flag LB & OB) at 30%.
Set it to 95% or something to test with to save running batteries up and down.EDIT: I just checked the manual and TL;DR
The first shutdown criteria initiates the restart of the shutdown sequence.
- If remaining time is under (0 to 99999 seconds, 180 by default) is the minimum remaining backup time
from which the shutdown sequence is launched. - If battery capacity is under (0 to 100%); this value cannot be less than that of the UPS and is the
minimum remaining battery capacity level from which the shutdown sequence is launched. - Shutdown after (0 to 99999 minutes, not validated by default) is the operating time in minutes left for
users after a switch to backup before starting the shutdown sequence. - Shutdown duration (120 seconds by default) is the time required for complete shutdown of systems
when a switch to backup time is long enough to trigger the shutdown sequences. It is calculated
automatically at the maximum of Shutdown duration of subscribed clients but can be modified in the
Advanced mode. - If battery capacity exceeds Minimum battery level to reach before restarting the UPS after utility
restoration
At the moment, FreeNAS shuts down after it has been on battery for 5 mins (configured via FreeNAS).
I would like pfSense to shut down when battery is approx 30% and the ups to shut down when it hits the low battery state of 20%
Will have to play with a few of these values. I read through the ussr manual prior but damn it confused me!
- If remaining time is under (0 to 99999 seconds, 180 by default) is the minimum remaining backup time
-
@Sir_SSV said in NUT package:
At the moment, FreeNAS shuts down after it has been on battery for 5 mins (configured via FreeNAS).
I would like pfSense to shut down when battery is approx 30% and the ups to shut down when it hits the low battery state of 20%
Staggering shutdowns like this may not be what you want. The problem comes when a system has initiated shutdown, but the mains return before the UPS enters a low battery state. Without a low battery state, the UPS will not cut / restore the load, and there will be nothing to trigger a restart of the system. It’s often better to configure the UPS and then let it manage shutdown.
-
@dennypage said in NUT package:
@Sir_SSV said in NUT package:
At the moment, FreeNAS shuts down after it has been on battery for 5 mins (configured via FreeNAS).
I would like pfSense to shut down when battery is approx 30% and the ups to shut down when it hits the low battery state of 20%
Staggering shutdowns like this may not be what you want. The problem comes when a system has initiated shutdown, but the mains return before the UPS enters a low battery state. Without a low battery state, the UPS will not cut / restore the load, and there will be nothing to trigger a restart of the system. It’s often better to configure the UPS and then let it manage shutdown.
During my testing over the weekend, this is what I noticed.
I have since scheduled a shut down of both FreeNAS and pfSense close to the low battery of the ups (20%).
-
I'm having a bit of trouble with the nut daemon starting when pfSense restarts from a complete shut down.
I found an earlier post and tried entering the below:
Extra arguments:
snmp_retries = 10
snmp_timeout = 2Get the error in System Logs
Poll UPS [Eaton] failed - Driver not connected
Removed the above Extra Arguments and entered the below:
ups.conf:
retrydelay = 30
maxretry = 20Get the error in System Logs
Data for UPS [Eaton] is stale - check driver
UPS [Eaton] data is no longer staleand it repeats the above error constantly until the service is stopped/restarted.
Once pfSense starts, if I manually stop and restart the service everything works ok!
Is there something I am doing incorrectly?
-
-
@dennypage said in NUT package:
@Sir_SSV Please see posts here and here
Make sure that the UPS is configured to use a static IP address, and that you are addressing the UPS by IP address and not by DNS name.
Thanks for the tip!
I had pfSense serving an ip address to the UPS via DHCP. I think the problem is the UPS boots very quickly and pfSense takes a little longer (UniFi switches take even longer again). The UPS wasn't being served it's allocated IP address in enough time and hence was causing the nut daemon to hang (and subsequent System Log errors and email alerts).
I removed the UPS from pfSense DHCP server and changed the Network settings via Eaton gui to Static and assigned an IP address on the UPS vlan . When pfSense starts, because the UPS has already started (and has it's own IP) the nut daemon can talk with the UPS and automatically update the status.
Final testing has been completed with both pfSense and FreeNAS shutting down once the UPS is at 24% and the UPS shutting down at 20% (factory set by Eaton).
Happy that everything has worked out and big thanks to everyone that helped
-
@Sir_SSV You're welcome.
-
I have an APC BX1000M that I recently connected to my pfsense box, running on an apu2c4, via usb cable. NUT is set to use usbhid as the driver.
apcupsd detects the UPS straight away and can poll it on demand, however NUT is not able to poll the device it seems. The logged messages apparently show that a login does occur, but then connection is immediately lost.
Jun 17 18:51:42 upsd 37544 Startup successful Jun 17 18:51:44 upsd 37544 User local-monitor@::1 logged into UPS [apcups] Jun 17 18:51:44 upsmon 37226 Poll UPS [apcups] failed - Driver not connected Jun 17 18:51:44 upsmon 37226 Communications with UPS apcups lost Jun 17 18:51:49 upsmon 37226 Poll UPS [apcups] failed - Driver not connected Jun 17 18:51:49 upsmon 37226 UPS apcups is unavailableI'm hoping this is a simple case of me overlooking something obvious, as so far my reading of this topic, the manual, and Google-fu has not gotten me anywhere, so any pointers would be greatly appreciated.
-
@turboturtle The "login" is the upsmon process connecting to upsd. It doesn't indicate anything about the actual UPS driver.
You are missing log entries for the driver itself. Look for entries matching "usbhid-ups" which is the NUT device driver for USB.
To address the most commonly experienced issue... if this is a fresh NUT install, you will need to either disconnect/reconnect the USB connection or reboot pfSense to have correct permissions on the USB port.
