NUT Package upssched setup

4o4rh

@dennypage It probably doesn't make sense, because you don't know the use case.

My pfsense doesn't have a connection to the UPS, which is on another floor.
It has a power pack to provide some running time to all for a controlled shutdown in the event power fails.
Power fails will only be recognized because the switches will lose power, so the comms to the UPS will fail (but any loss of comms will be treated the same i.e. switch reboot, etc)

I therefore need to;

consider a communications loss, firstly as a routine event and wait a period of time before shutting down
shutdown before the powerpack battery fails
cancel the shutdown if the communications is restored before the shutdown moment.

So, if;

normally reboot of a device, system will not shutdown because comms will be restored
power fails is only short interruption, system will not shutdown because comms will be restored
power fails, but is longer than the battery time of the power pack full shutdown will occur and system will need to be manually restarted (netgear switches don't provide Wake on LAN)

But I rather have the system shutdown in a controlled way, that cut off due to power failure. I lost a full pfsense config once, hence the reason i bought the power pack

dennypage

@gwaitsi Put your switch on the ups. Or use a direct connection.

4o4rh

@dennypage the UPS is 3 floors higher and there is no space/place for me to put a UPS where the pfsense is. The UPS protects my NAS in critical computers during an outage. given the switches, modems and access points have no protection, the pfsense does not a UPS. It only needs to stay up long enough for a controlled shutdown.

dennypage

@gwaitsi So the ups is not powering the pfSense box?

4o4rh

@dennypage no

dennypage

@gwaitsi Then don’t use nut. A simple shell script running on pfSense will do. Ping the switch, and if the ping fails for X min, execute a shutdown.

Btw, looking back at your first post, item 3 (fsd) would not work either. If the switch fails when the power fails, you would loose comms and never receive an fsd notice from the nut server.

4o4rh

@dennypage It would be could if you could include these two files as part of the configuration options in the package.

I have the use case almost working as desired, but i have to add these files to make it work

dennypage

@gwaitsi This isn’t a reasonable use case for nut.

4o4rh

@dennypage @jimp the use case is irrelavent in terms of these two files.

upssched.conf is the configuration for upssched timer program which is triggered through upsmon

The 2nd file /usr/local/bin/upssched-cmd is the CMDSCRIPT used for action events that have been triggered via the timer.

It's all in the documentation, and a quick seach on google shows many people using this for different kinds of use cases, particularly where multiple UPS's are involved.

https://networkupstools.org/docs/man/upssched.conf.html
https://networkupstools.org/docs/man/upssched.html

We shouldn't need to create outside the application, files that should be part of the package.

dennypage

@gwaitsi I don’t know what else to say to you. You are pursuing something that doesn’t make any sense to use nut for. Just write a simple shell script and move on.

4o4rh

@dennypage i already have it working, and that is the whole point of nut remote monitoring. i.e. to shutdown other systems. but neither of those points have anything to do with the fact the nut package, does not include an editor for two files that form part of the package e.g. upssched.conf and upssched-cmd

dennypage

@gwaitsi said in NUT Package upssched setup:

@dennypage i already have it working

Congratulations. Super cool.