NUT package : pfSense as slave : shutdown issues



  • Software: pfSense 2.4.3-p1 (FreeBSD 11.1-Release-p10)
    Hardware: Watchguard Firebox x750e with internal HDD

    Trying to protect my pfSense box using NUT (Network UPS Tools).
    PROBLEM: shutdown of pfSense via NUT results in Reboot, not Halt as expected. Looking for tips on how to troubleshoot.

    Configuration:
    UPS is directly connected to an Ubuntu server configured as MASTER. Tested, working fine.
    pfSense box is configured as a SLAVE. Shows NUT Status correctly in pfSense GUI. Initiates shutdown of pfSense on issue of FSD notice from MASTER.

    Additional upsmon.conf configuration options entered in “Advanced” section of pfSense NUT package GUI as follows:

    POLLFREQ 5
    POLLFREQALERT 5
    HOSTSYNC 15
    DEADTIME 15
    FINALDELAY 5
    

    SHUTDOWNCMD in /usr/local/etc/nut/upsmon.conf verified as:

    SHUTDOWNCMD "/sbin/shutdown -h +0"
    

    Entering this command at the console (hit option 8, then type at the command prompt) puts the pfSense box into a HALT state, as expected. However, when the same instruction is triggered through NUT in response to a FSD from the MASTER, pfSense does not enter a HALT state. Instead it performs a REBOOT.

    Can anyone suggest how I might find out what’s happening to cause this? I’ve confirmed the NUT user uucp is a member of the ‘operators’ group and therefore has permissions to run /sbin/shutdown.

    Thanks



  • Further testing has revealed this is not a problem specific to NUT, but a general problem with pfSense running on this particular hardware configuration.

    Running the command /sbin/shutdown -h +0 (or /sbin/shutdown -p +0) from the console brings the system down a HALT state where the console message is displayed “Press any key to reboot”.

    Triggering the same command outside a console session (e.g. from the pfSense WebGUI Diagnostics > Command Prompt or even Diagnostics > Halt System) causes a reboot.

    I will post a modified question in the appropriate support forum in the hopes of finding a solution to this behavior.


 

© Copyright 2002 - 2018 Rubicon Communications, LLC | Privacy Policy