Giving the Proxmox server a UPS, part 1: installation (June 2023)

All the R520 server posts can be viewed via the R520 tag.

After setting this R520 server up with Proxmox in July 2021 or so, I left this server largely powered off. This is because though the server takes surprisingly little power from what I would expect (about 150 watts at idle), leaving it on 24/7 does get expensive.

Note: this article is about initial setup of and troubleshooting of the UPS with the server. Part 2 will will cover the powering off signals etc.

And it’s not as though it has become any less expensive now. I just happened to have an idea of what I can use it for and I would like to get it setup to at least occasionally use.

But before I could even get into those purposes…I needed a way to make the server cleanly and safely power itself off when there’s a power failure. This is because I am running mechanical hard drives and though ZFS is very robust that doesn’t mean powering it off with a sudden outage is a great idea (California and power reliability doesn’t exactly have a great track record). The containers and virtual machines will be triggered by the host OS separately to power themselves down.

I bought this expensive UPS just for this purpose quite a while ago (around 2020 or so). Just the UPS by itself requires some wattage before the R520 has even been plugged in.

I bought the tower version of the APC SMC1000C (I now regret not getting the 2U version).

The first step is this UPS future was to figure out what I needed to install in Linux to make the server and the UPS talk to each other. This is where the first hurdle came in: the UPS has a male USB-A port. Not a female USB-A port, not a more standard for UPS USB-B port, but a male USB-A port. Which would be fine if I could find the cables that came with the UPS but I seem to have misplaced it. Fortunately I found a USB-C to USB-A adapter I happened to already have. That wasn’t that hard but it wasn’t a great start, either.

Next, I had to find out what to install on Linux so I did what any rational, advanced-level Linux administrator would do: I asked ChatGPT.

Well I did get the name of a program to install: apcupsd. That’s about where the helpfulness of ChatGPT ended. In retrospect I should have stopped there and found the man page of apcupsd (and associated pages) to learn what do next, but instead I decided to continue asking GPT questions.

Note: I'm using the sudo command here but this isn't always available, especially on Debian based systems. Basically, when you see sudo it just means something has to be run with root access. 

Note 2: in case below isn't clear on this: the USB cable connecting the PC to the UPS can be connected at any time. Should probably make that the first step.

Note 3: Below is ONLY about getting the server and UPS to talk to each other. I haven't even started on the power-down trigger part. I didn't even know the simple act of talking to each other would take so long. Stay tuned for the next part that might provide "useful" information.

Note 4: Obviously, this only applies to USB connections between Linux and the UPS. For serial, network and anything else this likely wouldn't help.

The first step is to install apcupsd (the -y part is optional, just means fewer prompts for “are you sure” and “continue”).

sudo apt-get install apcupsd -y

This part went through without any issues. The difficult part came in when I tried see if the OS could actually see the UPS. As per ChatGPT’s suggestion, I issued the command:

apcaccess status

This returned this status output, not what I was hoping for:

APC      : 001,017,0422
DATE     : 2023-06-02 17:59:08 -0700  
HOSTNAME : LarkBox
VERSION  : 3.14.14 (31 May 2016) debian
CABLE    : USB Cable
DRIVER   : USB UPS Driver
UPSMODE  : Stand Alone
STARTTIME: 2023-06-02 17:54:54 -0700  
STATUS   : COMMLOST 
MBATTCHG : 5 Percent
MINTIMEL : 3 Minutes
MAXTIME  : 0 Seconds
NUMXFERS : 0
TONBATT  : 0 Seconds
CUMONBATT: 0 Seconds
XOFFBATT : N/A
STATFLAG : 0x05000100
END APC  : 2023-06-02 17:59:08 -0700  

If it isn’t obvious, this is too little output and the status says COMMLOST.

After “conversing” with ChatGPT a while, ran this command to check on the status of the apcupsd service:

sudo systemctl status apcupsd

Which lead me to the (snippet) output below. I haven’t really used Linux extensively since before systemd became standard so I’m not clear why some of this verbose language is necessary.

Regardless of eccentric output of the services status, I still wasn’t any closer to making the server talk to the UPS.

Jun 02 17:54:54 LarkBox systemd[1]: Starting UPS power management daemon...
Jun 02 17:54:54 LarkBox apcupsd[3494]: apcupsd 3.14.14 (31 May 2016) debian startup succeeded
Jun 02 17:54:54 LarkBox systemd[1]: apcupsd.service: Can't open PID file /run/apcupsd.pid (yet?) after start: Operation not>
Jun 02 17:54:54 LarkBox systemd[1]: Started UPS power management daemon.

What threw me off was that Can’t open PID file /run/apcupsd.pid (yet?) part of the error message. And ChatGPT’s inaccurate approach to the error just made the issue that much harder, as it turned out. I was adjusting permissions and changing ownerships of different files…it was a whole thing (and it didn’t work).

I was able to copy/paste the text of some of this error into Google (hoping to find more useful information than ChatGPT): I found an old forum post from 2013 that provided me with some clues. Namely about the right lines in the config file and some information on the “lock file”.

Presenting…the solution

As it turns out, I needed to adjust a couple of lines in the default configuration file of apcupsd and create a single file.

When apcupsd is first installed, a configuration file is created:

/etc/apcupsd/apcupsd.conf

Optional: before editing this file, make a copy of it so you can fall back on a “clean” version if you need to – the actual name of the copy isn’t that important:

sudo cp /etc/apcupsd/apcupsd.conf /etc/apcupsd/apcupsd.conf.original

Next you should stop the services while working on the config file. This will make it easier when we’re done:

sudo systemctl stop apcupsd

Next – this part can be done multiple ways – you want to open the conf file using sudo and make some edits. You can use a text editor like vim or nano, a graphical editor in X Windows or utilize the feature of the web UI provided by Webmin (I wrote a short article on installing this). Whichever way you want to do it, these are the edits:

sudo vim /etc/apcupsd/apcupsd.conf

(don’t use vim unless you already know how to use vim)

You want one and only line with the word DEVICE. So you’d comment out the line, so it looks like this:
#DEVICE /dev/ttyS0
and make that line look like:

DEVICE

that’s it. Just DEVICE by itself on one line.

Next, you want to comment out the existing LOCKFILE line and make your line into this:

LOCKFILE /var/lock/subsys

Those are the only two edits I made. The default values can all be left as they were.

Save the file/quit out of whatever editor.

The last step is to create that lock file we referenced in the configure file with the touch command:

sudo touch /var/lock/subsys/apcupsd

The last step is to restart the apcupsd service:

sudo systemctl restart apcupsd

And you can double check the status:

apcaccess status

Assuming everything went as it should, you should see the full status-OK output of the command:

APC      : 001,027,0666
DATE     : 2023-06-02 18:50:34 -0700  
HOSTNAME : CapricaProx
VERSION  : 3.14.14 (31 May 2016) debian
UPSNAME  : CapricaProx
CABLE    : USB Cable
DRIVER   : USB UPS Driver
UPSMODE  : Stand Alone
STARTTIME: 2023-06-01 14:56:11 -0700  
MODEL    : Smart-UPS_1000 
STATUS   : ONLINE 
BCHARGE  : 100.0 Percent
TIMELEFT : 4.3 Minutes
MBATTCHG : 5 Percent
MINTIMEL : 3 Minutes
MAXTIME  : 0 Seconds
ALARMDEL : No alarm
BATTV    : 25.9 Volts
NUMXFERS : 0
TONBATT  : 0 Seconds
CUMONBATT: 0 Seconds
XOFFBATT : N/A
STATFLAG : 0x05000008
MANDATE  : 2020-05-21
SERIALNO : [redacted]    
NOMBATTV : 24.0 Volts
FIRMWARE : UPS 04.1 / ID=1018
END APC  : 2023-06-02 18:50:38 -0700  

As you can see, the STATUS is now ONLINE and there is much more information. You can also see the UPS thinks it can only give me about 4 minutes of juice before powering off. I haven’t tested it yet but I hope that is not an accurate assessment.

References and Resources

• An old forum post from 2013 that clued me in to the answer (linux questions.org)
• Man page to for APCUPSD daemon
• My first post about Proxmox and the R520
• A prior post on status of server: Lets try this again
• An explanation of Hyper-V networking thanks to altaro.com
• Hyper-V Server 2019 post about setting up storage pool
• Hyper-V server 2019 post about first-setup, networking, RDP etc
• Day 31 of my 100 days of code has some information (day 32 has some info too)
• I also wrote a post about the R520 in particular
• General information on deploying storage spaces (MS Docs)
• PowerShell reference for disk-related tasks (MS Docs)

All the R520 server posts can be viewed via the R520 tag.