Apr 28, 2021 3 min read

Experiments with apcupsd in Debian/Proxmox: Answers to Questions You Didn't Know You Had

Experiments with apcupsd in Debian/Proxmox: Answers to Questions You Didn't Know You Had
Table of Contents

While setting up an apcupsd client on Proxmox, a bunch of questions crossed my mind about the behavior of the apcupsd daemon. I did the experiments to get answers so you don't have to. I hope you find the below apcupsd Q&A helpful. Hopefully it will help you design a better homelab network.

What is apcupsd?

Apcupsd is a program/daemon used for monitoring an uninterruptable power supply (UPS). It's mainly used to inform a server when its running on battery so that the server can safely perform a graceful shutdown (as opposed to just running the UPS battery to exhaustion and abruptly losing power).

Does apcupsd automatically shutdown "killpower" the UPS outlets?

Yes, at least in Debian and by extension Proxmox (which runs on Debian). Apparently apcupsd's maintainers decided that the UPS should enter hibernation once the server powers down. Hope you didn't have anything else running on that UPS...

Should I prevent apcupsd from automatically shutting down "killpower" the UPS? Is this default behavior a bad thing?

Not necessarily. It depends on what else is on that UPS. If you've set up all the other machines on that UPS with an apcupsd client so that they have time to properly shutdown before the apcupsd server forces the UPS into hibernation, then this default behavior is fine, even desirable since it means that you won't have to wake the devices up later with an external WOL (wake-on-LAN) packet.

However, in my situation, I only have one UPS feeding my servers and my core network equipment (modem, router, wireless APs, and network switches) and I want them to stay up as long as possible, so I don't want apcupsd's default behavior.

But will my devices power back on automatically when the UPS has been shutdown and power is restored?

Yes, but you must have "AC Back" set to "Always" in your BIOS's power management options. Modern systems can detect a change in power state so that the loss of power to the PC, followed by the restoration of power, can automatically boot it (even when the system is fully shutdown).

This is what the apcupsd is banking on when it shuts down the UPS outlets. Later, when utility power is restored, the UPS outlets will power back on and the connected machines will sense this change in power state, prompting them to boot back up.

How do I prevent apcupsd from automatically shutting down ("killpower") the UPS?

There's a couple of ways to prevent apcupsd from forcing the UPS into hibernation.

Right now, Debian uses a script in /lib/systemd/system-shutdown/apcupsd_shutdown and /usr/lib/systemd/system-shutdown/apcupsd_shutdown. You could remove those scripts, but they'll only come back in a future update. Instead, I recommend editing /etc/apcupsd/killpower to change exit 0 to exit 99. With this change (and the rest of the script above it commented out, which it is by default), apccontrol will only run our "customized" script, effectively nerfing it.

I'm running apcupsd in an NIS server/client (master/slave) configuration. Does this mean that the apcupsd client will shutdown/killpower the UPS and take out power to my other devices?

No. In my testing with a Proxmox server configured as an apcupsd client/slave (UPSCABLE ether and UPSTYPE net), the apcupsd daemon appears unable to shutdown the UPS/force it into hibernation.

I tested this by unplugging the UPS with my apcupsd master/server still up and setting an incredibly low threshold for shutdown on my Proxmox/Debian apcupsd client. The apcupsd client successfully shutdown, while the apcupsd master server did not. All of the devices on both sides of the UPS maintained stayed on, indicating that power was not lost. Even after allowing for a 90 second delay (APC's default).

If I'm running apcupsd in an NIS server/client configuration, and the master NIS server shuts down first, will the client also shutdown?

According to the documentation, in theory, yes:

Any client run using the Net driver will shutdown when its own timers expire or when the NIS server shuts down, whichever occurs first.
Source: APCUPSD User Manual

However, in my own testing, I have found this to not be the case, at least not in Debian/Proxmox. Shutting down the master server, I do start firing the commfailure events on the client. However apccontrol doesn't seem to do anything with them, even after ten minutes. And I don't see anything in appcontrol where I would expect it to do anything either, so I don't think I'm missing anything either.

In other words, in Debian/Proxmox, if the master NIS server shuts down, the clients will not.

Causes? It's entirely possible that Debian doesn't use Net driver with apcupsd. Or maybe the APCUPSD user manual is talking about shutting down its own NIS server on the client...but that would be weird.


Hopefully you've found these apcupsd questions and answers useful, so you don't have to spend hours trying to track them down on Google.

Great! You’ve successfully signed up.
Welcome back! You've successfully signed in.
You've successfully subscribed to The Engineer's Workshop.
Your link has expired.
Success! Check your email for magic link to sign-in.
Success! Your billing info has been updated.
Your billing was not updated.