{"id":1482,"date":"2025-11-09T11:45:42","date_gmt":"2025-11-09T17:45:42","guid":{"rendered":"https:\/\/www.nathanhunstad.com\/blog\/?p=1482"},"modified":"2025-11-09T11:45:43","modified_gmt":"2025-11-09T17:45:43","slug":"scheduling-auto-shutdown-with-nut","status":"publish","type":"post","link":"https:\/\/www.nathanhunstad.com\/blog\/2025\/11\/scheduling-auto-shutdown-with-nut\/","title":{"rendered":"Scheduling auto-shutdown with NUT"},"content":{"rendered":"\n

In my last blog post<\/a>, I walked through building NUT from source to monitor my new APC UPS. Why monitor a UPS? While one benefit is that I can get a bunch of pretty graphs for my Kibana dashboard, there’s a much more practical reason: monitoring the UPS allows my servers to shut themselves off if necessary on a set schedule. In this blog post I’ll explain how I set this up.<\/p>\n\n\n\n\n\n\n\n

There are many reasons to use a UPS, and one is to allow for a clean shutdown when the power goes out, instead of just hoping for the best as power drops with no warning. This can work fine, but in my case I have a goal of maximizing the runtime of my UPS for my network. <\/p>\n\n\n\n

For my setup, I have my fiber modem, router, and switches on my UPS in addition to a couple of servers. I could just let them all run on battery power until it runs out, but instead I want to shut my servers down if the power is out for more than a few minutes as opposed to just a temporary blip. Fortunately, this is a doable task, and below is how I did it.<\/p>\n\n\n\n

Basic configuration<\/h2>\n\n\n\n

There are a couple of binaries you need to set up to monitor UPS status: upsd <\/code>and upsmon<\/code>. Upsd<\/code> is the daemon that serves data to clients that are monitoring a UPS, and upsmon<\/code> does the monitoring, natch. First comes upsd<\/code>: since I want other servers to be able to get data on the UPS over the network, I added the following to upsd.conf<\/code> in \/etc\/nut <\/code>to allow upsd<\/code> to listen on the network interface:<\/p>\n\n\n\n

LISTEN 0.0.0.0 3493<\/code><\/pre>\n\n\n\n
Next came upsd.users<\/code>, which allows for some minimal amount of access control. Nothing fancy here nor a strong password, since this is all internal and I’m not terribly worried about security. This is the user I added to upsd.users<\/code>:<\/p>\n\n\n\n
        [upsmon]\n                password = secret\n                upsmon primary\n                actions = SET\n                instcmds = ALL\n<\/code><\/pre>\n\n\n\n
After that I moved on to the upsmon<\/code> configuration. There is some good documentation<\/a> available which came in handy, since I needed to set up a few options here. First was the MONITOR block:<\/p>\n\n\n\n
MONITOR apcups@localhost 1 upsmon secret primary<\/code><\/pre>\n\n\n\n
This says I want to monitor my APC UPS on localhost, using the username and super-secret password above. “Primary” means that the UPS is connected to the host that upsmon<\/code> is running on, versus a different host. Easy!<\/p>\n\n\n\n
Getting fancy with upssched<\/h2>\n\n\n\n
Next, I needed to modify how we wanted to handle shutdowns. By default<\/a>, upsmon<\/code> will not signal a shutdown until the battery reaches a critical level. This is not what I wanted however: I want to shut down my servers well before that. As a result, I needed to do something advanced<\/a>: use upssched<\/code> to schedule a shutdown after X minutes on battery power. This required a bit of extra work.<\/p>\n\n\n\n
Step one: set the NOTIFYCMD<\/code> in upsmon.conf<\/code> to upssched<\/code>. For whatever reason, the example in the file they gave had the wrong path, so make sure you run “which upssched” to get the right one! In my case it was this:<\/p>\n\n\n\n
NOTIFYCMD \/usr\/sbin\/upssched<\/code><\/pre>\n\n\n\n
Now we need to have upsmon<\/code> run that binary when we get a few key messages: when the UPS is on battery, when it is back on line power, and when the battery is critical (just for funsies). I did this by modifying the NOTIFYFLAG<\/code> lines as such to add EXEC<\/code> to those flags, which as the documentation says will signal to NOTIFYCMD<\/code> when those events happen:<\/p>\n\n\n\n
NOTIFYFLAG ONLINE       SYSLOG+WALL+EXEC\nNOTIFYFLAG ONBATT       SYSLOG+WALL+EXEC\nNOTIFYFLAG LOWBATT      SYSLOG+WALL+EXEC<\/code><\/pre>\n\n\n\n
That brought me to the upssched.conf<\/code> file, which needed a few changes as well. The CMDSCRIPT<\/code> stayed the same, but I modified it with the changes below. The PIPEFN<\/code> and LOCKFN<\/code> lines gave me a lot of trouble until I modified those lines as well to provide the right permissions for the stated files, since the wrong permissions resulted in upssched<\/code> failing to run for my first tests. This is what I used:<\/p>\n\n\n\n
PIPEFN \/run\/nut\/upssched\/upssched.pipe\nLOCKFN \/run\/nut\/upssched\/upssched.lock<\/code><\/pre>\n\n\n\n
Finally, the heart of the work. For my monitoring server, I wanted it to shut down after 5 minutes on battery power. Upssched<\/code> has timers to do this, so I added this pair of lines to start the timer when running on battery, and crucially cancel it when back on line power:<\/p>\n\n\n\n
AT ONBATT * START-TIMER timedshutdown 300\nAT ONLINE * CANCEL-TIMER timedshutdown<\/code><\/pre>\n\n\n\n
What is timedshutdown<\/code>? That’s essentially the argument that is passed to the CMDSCRIPT<\/code> when the timer is done. Remember a few paragraphs up when I said I changed this?  As the doc says, it’s basically one big case..esac block, so I put the following block in to handle that timedshutdown<\/code> signal:<\/p>\n\n\n\n
        timedshutdown)\n                # Set shutdown flag\n                \/usr\/sbin\/upsmon -c fsd<\/code><\/pre>\n\n\n\n
That last line is what sets forced shutdown mode. <\/p>\n\n\n\n
To sum up what I did:<\/p>\n\n\n\n
    \n
  1. If the UPS is on battery, start a timer for 5 minutes<\/li>\n\n\n\n
  2. When the timer reaches 0, set the forced shutdown flag<\/li>\n\n\n\n
  3. If the UPS gets back on line power before 5 minutes is up, then cancel the timer<\/li>\n<\/ol>\n\n\n\n
    Monitoring remotely<\/h2>\n\n\n\n
    That took care of my primary monitoring server, but I have more than one server I want to monitor the UPS. For remote monitoring from my other server, I did the same thing with a few tweaks:<\/p>\n\n\n\n
      \n
    1. the MONITOR line in upsmon.conf has the server name instead of localhost, and “secondary” instead of “primary”.<\/li>\n\n\n\n
    2. I want the secondary servers to shut down first, so I set a shorter timer (3 minutes).<\/li>\n<\/ol>\n\n\n\n
      The test<\/h2>\n\n\n\n
      After all of this was configured and I figured out the pipe and lock file permissions, it was time for the test: I pulled the power plug for the UPS and waited. As configured, one server shut down at 3 minutes and the other at 5. Success!<\/p>\n\n\n\n
      With this setup, if I experience a lengthy power outage, I will lose my nice Elastic dashboards, Home Assistant, and other apps running on those servers, but hopefully I will be able to use my network for as long as possible.<\/p>\n\n\n\n
      <\/p>\n","protected":false},"excerpt":{"rendered":"
      Read on to learn how to use upsmon and upssched to shut down a server on a timer when on UPS battery.<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"om_disable_all_campaigns":false,"_monsterinsights_skip_tracking":false,"_monsterinsights_sitenote_active":false,"_monsterinsights_sitenote_note":"","_monsterinsights_sitenote_category":0,"footnotes":""},"categories":[19],"tags":[21,308],"class_list":["post-1482","post","type-post","status-publish","format-standard","hentry","category-tech-2","tag-linux","tag-ups","entry"],"aioseo_notices":[],"_links":{"self":[{"href":"https:\/\/www.nathanhunstad.com\/blog\/wp-json\/wp\/v2\/posts\/1482","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.nathanhunstad.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.nathanhunstad.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.nathanhunstad.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.nathanhunstad.com\/blog\/wp-json\/wp\/v2\/comments?post=1482"}],"version-history":[{"count":2,"href":"https:\/\/www.nathanhunstad.com\/blog\/wp-json\/wp\/v2\/posts\/1482\/revisions"}],"predecessor-version":[{"id":1484,"href":"https:\/\/www.nathanhunstad.com\/blog\/wp-json\/wp\/v2\/posts\/1482\/revisions\/1484"}],"wp:attachment":[{"href":"https:\/\/www.nathanhunstad.com\/blog\/wp-json\/wp\/v2\/media?parent=1482"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.nathanhunstad.com\/blog\/wp-json\/wp\/v2\/categories?post=1482"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.nathanhunstad.com\/blog\/wp-json\/wp\/v2\/tags?post=1482"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}