NUT package (2.8.0 and below)

dennypage

@mrsunfire Hmm... I would have expected there to be some config change, either in the NUT package or in the UPS, as the UPS should not be bringing the load back on that quickly (0%). Nor would I expect it to show "On Line" and "Discharging" like that unless a calibration cycle were underway.

Speaking thereof, have you run a battery calibration recently? Perhaps the battery is dead...

Lastly, can you post the output of upsrw?

mrsunfire

@dennypage No calibration. I wo der why UPS switches back on battery the moment I connect pfSense.
Whats the command for that output?

dennypage

@mrsunfire How old it the UPS and battery?

Please post the output of upsrw. If you aren't familiar with that, you can find examples in this thread.

JonathanLee

@mrsunfire I was having weird issues in the last and it turned out to be a bad battery not the software.

mrsunfire

@jonathanlee Yes I already ordered new batteries before continue further testing.

I also did edit upsmon.conf and removed "SHUTDOWNCMD "/sbin/shutdown -h +0"". Unfortunately after reboot this setting is back there. How to proper edit that file? My goal in the first step was to not shutdown the pfSense at all.

Gertjan

@mrsunfire said in NUT package:

Unfortunately after reboot this setting is back there. How to proper edit that file? My goal in the first step was to not shutdown the pfSense at all.

Fast answer : you can't.
As the GUI states, this is what gets inserted in that file :

And this is what gets inserted upfront by the GUI interface, even when you leave that bloc empty :

/usr/local/pkg/nut/nut.inc line 250->252

( so, edit that file and do whatever you want ^^ )

dennypage

@mrsunfire said in NUT package:

I also did edit upsmon.conf and removed "SHUTDOWNCMD "/sbin/shutdown -h +0"". Unfortunately after reboot this setting is back there.

You can't. If you want to prevent NUT operation (shutdown and everything else), change the UPS Type to disabled until you replace the battery.

darkcorner

I have an APC Back-UPS BX2200MI connected and configured in pfSense.
Everything seems to work fine.
But how and where can I customize the shutdown delay?
I want it to turn off when the battery guarantees me no more than 10 minutes of electricity.
If within these 10 minutes the current returns, what happens?
What if pfSense has shut down in the meantime? The BIOS is configured for the PC to turn on when the power returns; is this enough?

dennypage

@darkcorner said in NUT package:

But how and where can I customize the shutdown delay?
I want it to turn off when the battery guarantees me no more than 10 minutes of electricity.

NUT will automatically shut the system down when the UPS declares a low battery situation. It is best to leave this alone and let the UPS and NUT do their jobs.

DannyBoy2k

@darkcorner If your UPS allows you to, you can configure battery.runtime.low to the amount of time you want the UPS to declare a critical condition. Unfortunately, a lot of UPSes don't allow you to configure this. If they do, you should be able to see and adjust the setting with the upsc command.
https://networkupstools.org/docs/man/upsc.html

darkcorner

@dennypage
@DannyBoy2k
Thanks for your answers.

The UPS USB cable is connected to pfSense, but it covers multiple PCs/servers that need to shut down automatically.
So, pfSense is the Master of NUT and on these PCs/Servers I'm installing tools configured as NUT Slave.

TrueNAS is configured as "Slave" in its NUT service, but it doesn't seem to notice the presence of the Master.
On a Win10 Pro PC I mounted WinNUT-Client and it gives me a login failure error for authentication.
(If it's not the right software, can you suggest me some other client?)

For all, the port is the standard one (3493).
In Windows10 I turned off its Windows Defender Firewall.
On pfSense there are two rules in LAN and DMZ for LAN-Net and DMZ-Net which allows any to any with any protocol.
In pfSense, with Diagnostic - Test Ports the port seems open, but from console telnet 127.0.0.1:3493 or (localhost:3493) reports the error "Name does not resolve".
On PC Win10 telnet LAN-NIC-Address:3493 reports error "Could not open connection to host. on port 23: Connection failed"

As NUT users I am using both admin and local-monitor with the password present in /usr/local/etc/nut/upsd.users.

Gertjan

@darkcorner said in NUT package:

On a Win10 Pro PC I mounted WinNUT-Client and it gives me a login failure error for authentication.

This one ?
I'm using several of them, pfSense being the NUT-master. It works.

pfSense side :

and

Note : my ups is called 'ups'.

On the Win NUT client side, a PC :

where password = "secret2" as this is "pcrecep1".

I've no particular firewall rules on my LAN, 19.168.1.1 - just one pass-all, so the client connects just fine.

@darkcorner said in NUT package:

In pfSense, with Diagnostic - Test Ports the port seems open, but from console telnet 127.0.0.1:3493 or (localhost:3493) reports the error "Name does not resolve".

You instructed NUT (pfSense) to listen on what interfaces ?
127.0.0.1 is not reachable from LAN. So
I want NUT to listen on my LAN so I told it to do so :

@darkcorner said in NUT package:

On PC Win10 telnet LAN-NIC-Address:3493 reports error "Could not open connection to host. on port 23: Connection failed"

telnet could be a good test.
But telnet uses TCP. Not sure if NUT uses UDP or TCP.

A better test : ask the system directly. I know the port, 3493, so :

[22.05-RELEASE][admin@pfSense.local.net]/root: sockstat | grep '3493'
root     upsd       21699 4  tcp6   2001:470:xxxx:5c0:2::1:3493 *:*
root     upsd       21699 5  tcp4   192.168.1.1:3493      *:*
root     upsd       21699 6  tcp6   ::1:3493              *:*
root     upsd       21699 7  tcp4   127.0.0.1:3493        *:*
root     upsd       21699 11 tcp6   ::1:3493              ::1:64823
root     upsd       21699 12 tcp4   192.168.1.1:3493      192.168.1.33:36453
root     upsd       21699 13 tcp4   192.168.1.1:3493      192.168.1.6:58694
root     upsd       21699 14 tcp4   192.168.1.1:3493      192.168.1.7:60690
root     upsmon     20768 4  tcp6   ::1:64823             ::1:3493

This tells you everything you need to know.
Nut listens on my LAN IPv6, and 192.168.1.1 all port 3493. Protocol is tcp.
PC's (clients) 192.168.1.6 and 192.168.1.7 have an established connection.
Like 192.168.1.33, my syno NAS, using 'monuser' and 'secret' as login ID.
Btw : ok, it listens also on localhost or 127.0.0.1 or ::1 on port 3493, tpc.

@darkcorner said in NUT package:

As NUT users I am using both admin and local-monitor with the password present in /usr/local/etc/nut/upsd.users.

True, this information :

will be placed into that file.
Do NOT edit that file yourself, use the GUI.

My "/usr/local/etc/nut/upsd.users" file has more info in it.
At the top, I find :

[admin]
password=be7b490cda2016c2a1fe
actions=set
instcmds=all
[local-monitor]
password=e90150cecfe29445f4a3
upsmon master

These are created when you install the package.
Not sure why I should use these. These [admin] and [local-monitor] are probably RTFM items.

edit :
By now, you have your clients up and connected.

So, bonus time :

The NOTIFYFLAG lines ask nut to spam logs, messages on the console, which can be seen if you are logged in console or SSH.

This one : "NOTIFYCMD /usr/local/sbin/upssched" is special.

You have to make your copy of this file : /usr/local/etc/nut/upssched.conf - take upssched.conf.sample as an example.
My /usr/local/etc/nut/upssched.conf :

CMDSCRIPT /root/upssched-cmd.sh
PIPEFN /var/db/nut/upssched.pipe
LOCKFN /var/db/nut/upssched.lock

AT ONBATT * START-TIMER onbatt 15
AT ONLINE * CANCEL-TIMER onbatt online
AT LOWBATT * EXECUTE lowbatt
AT COMMBAD * START-TIMER commbad 30
AT COMMOK * CANCEL-TIMER commbad commok
AT NOCOMM * EXECUTE commbad
AT FSD * EXECUTE powerdown
AT SHUTDOWN * EXECUTE powerdown

and before you ask : here is my home made /root/upssched-cmd.sh :

#!/bin/sh

UPS="ups"
STATUS=$( upsc $UPS ups.status )
CHARGE=$( upsc $UPS battery.charge )
CHMSG="[$STATUS]:$CHARGE%"

# upssched-cmd  --slave --
/usr/bin/logger -i -t upssched-cmd Calling upssched-cmd $1

case $1 in
    online) 
    MSG="$UPS, $CHMSG - power supply has been restored."
    ;;
    onbatt)
    MSG="$UPS, $CHMSG - power failure - save your work!"
    ;;
    lowbatt) 
    MSG="$UPS, $CHMSG - shutdown now!"
    ;;
    upsgone)
    MSG="$UPS, $CHMSG - UPS has been gone for awhile"
    ;;
    powerdown)
    MSG="$UPS, $CHMSG - Going powerdown"
    ;;
    commbad)
    /usr/bin/logger -i -t upssched-cmd "Communcation with UPS is lost"
    ;;
    *) 
    /usr/bin/logger -i -t upssched-cmd "Unkown arg: \"$1\", $CHMSG"
    exit 1
    ;;
esac
/usr/bin/logger -i -t upssched-cmd $MSG
/usr/local/pkg/nut/nut_email.php $MSG
exit 0

Make this file executable :

chmod +x /root/upssched-cmd.sh

and be careful for the file encoding. (Unix LF UTF-8, not some Windows format)

It's this file that takes care of the mail sending when power events happen.

Do not use this option :

as it hard codes a mail transmission, and blast away other possible settings.
=> Never ask a stupid GUI to do something that you can do yourself better ;)
The thing is : there can only be ONE CMDSCRIPT in /usr/local/etc/nut/upssched.conf.

Check the GUI 'mail me' option and that places the CMDSCRIPT. I wanted to have some more control of the process.
As you ca see, I use the NUT mail php script to mail : "/usr/local/pkg/nut/nut_email.php $MSG".

I'm using the settings and files as shown. I'm not saying they are perfect. I just want the systems to go down as soon as a power loss event arrives.

Btw : and yes, NUT is quiet big, and you can make it as complex as you want.
Testing is important, and you have to test a lot. No testing means : you have an UPS and you still have a no controlled power loss which might translate in data loss.

dennypage

@darkcorner said in NUT package:

The UPS USB cable is connected to pfSense, but it covers multiple PCs/servers that need to shut down automatically.
So, pfSense is the Master of NUT and on these PCs/Servers I'm installing tools configured as NUT Slave.

Please see post #2 in this thread for information on allowing remote access to the NUT server.

darkcorner

@Gertjan
Thank you, your suggestions have been very valuable.
I haven't tested them all yet because I had to deal with another problem at the office, but it will be the first thing I do tomorrow (Monday).
But now WinNUT-Client has immediately detected the status of the UPS.

In the meantime, I want to ask you a few other things, hoping not abusing your courtesy.

I also read in other comments that the name is "ups"; is it perhaps binding? I named mine as the model of UPS (Back-UPS_BX2200MI)
I haven't seen how to run a script from WinNUT-Client yet. Do you have a suggestion about it?
In your opinion, an ESXi host server (Free) and a Proxmox server is better to shut down by a command executed from WinNUT-Client, or directly from the script on pfSense?

dennypage

@darkcorner said in NUT package:

I also read in other comments that the name is "ups"; is it perhaps binding? I named mine as the model of UPS (Back-UPS_BX2200MI)

People often use the name "ups" because some NUT installations, particularly those on NAS, are hardcoded to use that name.

darkcorner

But I didn't understand how to get pfSense and the servers to turn on after they shut down.
There is a delay. If the power returns before the shutdown has started, everything will stay on. And that's OK.
But two cases can arise, especially in the evening when nobody is there.

The power is back, but the shutdown has already started or maybe pfsense and the servers are already off.
Power has returned, but the battery is now dead and the UPS is off.

Sure, one person can turn everything back on, but what if you want the machines to turn themselves back on?

4o4rh

@darkcorner
2. is not an issue. this can be solved through the bios setting.
i.e. acpi settings to power on upon restoration of power.

it is 1. that is a problem. i.e. the system shutdown because the timer has determined to shutdown, but the battery hasn't expired before the restoration of power. now there is no way to wake the system up, unless you can use a WakeOn LAN function. But so far, i haven't worked out how to make the switch cause a wake-on situation for the pfsense box

dennypage

@darkcorner

Regarding 1: Once a low battery situation is declared, NUT begins the shutdown process. Once this starts, it does not stop. The process includes instructing the UPS to cut power, and this will happen regardless of whether or not the mains have been restored. So what happens is that the UPS cuts the power, and after a brief interval restores power. The attached systems should be configured to boot automatically when power is applied.

Regarding 2: UPSs are generally designed/configured to not restore power until there is a certain percentage of battery charge available. The reason for this is to ensure that systems can safely shutdown again in the event of a subsequent power failure. Often this percentage defaults to 25% or more, but may be configurable. Look to your UPS documentation or consult with the UPS vendor for more information.

4o4rh

@dennypage
I believe in 1: we are saying the same thing. The option to boot automatically when power is applied, is a bios setting (i believe under the ACPI settings from memory).

In 2: actually i was thinking of a slightly different scenario, but same principle.
i.e. where the remote device being shutdown, has a dumb battery.
In this situation, it is possible the remote device is shutdown before the battery dies, so when power is replied, there is no way to power up, as the device never lost power.
This is a similar situation to the one described i.e. where power to the UPS is restored, but because the battery died, the UPS doesn't automatically turn on. Although in this scenario, wake-on lan wouldn't work anyway because the UPS hasn't powered on.

dennypage

@gwaitsi said in NUT package:

i.e. where the remote device being shutdown, has a dumb battery.
In this situation, it is possible the remote device is shutdown before the battery dies, so when power is replied, there is no way to power up, as the device never lost power.

FWIW, I've never heard of a "dumb battery" UPS that does not re-energize the load when mains return and the battery has reached a sufficient level. I definately would not recommend such a device for use with NUT.