apcupsd works ??!!

[2manycables]

I just got a QNAP and wanted to share the UPS with a PC. I searched this forum and what I found on apcupsd wasn't encouraging. Looking at the gpl source code for the QNAP (firmware 3.1.1) the apcupsd code version is 3.10.15 (from 2004!!; current version is 3.14.8). Also my APC is not on the compatibility list (APC Back-UPS XS 1300 LC, mfgr 11/2007, USB cable).

But when I saw apcupsd in /sbin, I still had to try.

Code: Select all

edit (additional info) ----------
[/sbin] # apcupsd &
no modification of apcupsd.conf required
--------------------------end edit

To my surprise, it worked flawlessly. My UPS sends the info to the QNAP which relays it over the network to my PC. Both gracefully shut down with UPS battery to spare when I pull the UPS plug.

Initially I used the web admin pages on the QNAP to configure the UPS, and this worked (config accepted, status shown, but not tested), but after doing this and looking at running processes I noticed the apcupsd daemon was missing. So, I disabled UPS management in the web admin pages (don't want two independent methods trying to run the show) and fired up apcupsd. To my unexpected delight, '/sbin/apcaccess status' showed correct info. I then configured apcupsd (3.14.8) on the PC to watch the QNAP and that worked too (though infomation is not quite as complete as when I hooked the UPS up to my PC and ran the current version of apcupd there for comparison).

So, all I've had to do on the QNAP is manually fire up apcupsd after a reboot. If I can figure out how to do this automatically (haven't researched yet) then this will have turned out to be much simpler than I thought it would be. Though I would like all the bug fixes and info enhancements that would come with a current version of apcupsd on the QNAP, things turned out much better than I had expected. Clearly not everyone here has had as nice an experience, but don't give up on apcupsd before trying it.

[Don]

Hi,

You can install apcupsd version 3.14.5-2 via ipkg. See my how-to guide in my signature for information on setting up autorun.sh.

[2manycables]

Thanks for the pointer. The guide in your sig is a definite time saver. I'd recommend any new (or veteran for that matter) QNAP user review it before surfing for answers. As to QPKG/IPKG, I'm taking small steps as I get comfortable.

[2manycables]

Well, I decided I might as well have to do a complete reset now rather than after there is lots of data on the NAS if the experiment to install apcupsd through ipkg fails. So following Don's lead, I decided to give it a try, and it didn't fail. As I still haven't found a step-by-step guide to this, here's what I did.

1 ) Log onto NAS web interface as admin and navigate to APPLICATIONS > QPKG plugins, click [GET QPKG]
on installation tab.

2 ) new window opens, click on 'Optware IPKG (Itsy Package Management System)'

3 ) at bottom of package, select correct link for your architecture (for me: Intel x86 [TS-x39 series/ x59 Series/ 509/ 809/ 809U-RP/ SS-439/ 839]) and save the file to some location on your PC.

4 ) unzip the downloaded file on your PC.

5 ) in web admin APPLICATIONS > QPKG plugins click on INSTALLATION tab

6 ) as instructed there, browse to the location where the unzipped file is, and then click [INSTALL]

7 ) after installation is complete, time to shift to console mode...

8 ) PuTTY into the NAS as admin; you'll find that ipkg is in the path and has been installed in [/opt/bin/ipkg]. Also, /opt is a symbolic link to the NAS volume: '# ls -alF /opt' gives:
lrwxrwxrwx 1 admin administ 29 Jan 19 19:39 /opt -> /share/MD0_DATA/.qpkg/Optware/

9 ) type 'ipkg help' to see what you can do with ipkg

10 ) type 'ipkg update' to download a current list of what is currently available:

Code: Select all

[/opt] # ipkg update
Downloading http://ipkg.nslu2-linux.org/feeds/optware/ts509/cross/unstable/Packages.gz
Inflating http://ipkg.nslu2-linux.org/feeds/optware/ts509/cross/unstable/Packages.gz
Updated list of available packages in /opt/lib/ipkg/lists/ts509
Successfully terminated.

11 ) you can type 'ipkg list' to see what is available

12 ) here goes (take deep breath and do the apcupsd ipkg install) ...

Code: Select all

[/sbin] # ipkg install apcupsd
Installing apcupsd (3.14.5-2) to root...
Downloading http://ipkg.nslu2-linux.org/feeds/optware/ts509/cross/unstable/apcupsd_3.14.5-2_i686.ipk
Configuring apcupsd
Successfully terminated.
[/] # find . | fgrep apcupsd
./etc/apcupsd
./etc/apcupsd/apcupsd.conf
./etc/apcupsd/apccontrol
./sbin/apcupsd
./share/MD0_DATA/.qpkg/Optware/etc/apcupsd
./share/MD0_DATA/.qpkg/Optware/etc/apcupsd/onbattery
./share/MD0_DATA/.qpkg/Optware/etc/apcupsd/multimon.conf
./share/MD0_DATA/.qpkg/Optware/etc/apcupsd/apccontrol
./share/MD0_DATA/.qpkg/Optware/etc/apcupsd/commfailure
./share/MD0_DATA/.qpkg/Optware/etc/apcupsd/changeme
./share/MD0_DATA/.qpkg/Optware/etc/apcupsd/apcupsd.conf
./share/MD0_DATA/.qpkg/Optware/etc/apcupsd/commok
./share/MD0_DATA/.qpkg/Optware/etc/apcupsd/offbattery
./share/MD0_DATA/.qpkg/Optware/etc/apcupsd/hosts.conf
./share/MD0_DATA/.qpkg/Optware/lib/ipkg/info/apcupsd.control
./share/MD0_DATA/.qpkg/Optware/lib/ipkg/info/apcupsd.conffiles
./share/MD0_DATA/.qpkg/Optware/lib/ipkg/info/apcupsd.list
./share/MD0_DATA/.qpkg/Optware/share/man/man8/apcupsd.8
./share/MD0_DATA/.qpkg/Optware/share/hal/fdi/policy/20thirdparty/80-apcupsd-ups-policy.fdi
./share/MD0_DATA/.qpkg/Optware/sbin/apcupsd
./tmp/apcupsd.pid

- note 1: The original (2004) apcupsd was in /sbin. The ipkg installed apcupsd is in /opt/sbin. So, it looks like one of my fears - that this process will overwrite old apcupsd - was unwarranted [ED: confirmed by Don in a subsequent PM].
- note 2: the apcupsd.ipkg downloaded for me is from http://ipkg.nslu2-linux.org/feeds/optwa ... 2_i686.ipk ... I closed my eyes as I saw the 'unstable' in that path name and just pressed forward because Don said it would work )

13 ) copy the /opt/etc/apcupsd/apcupsd.conf file to apcupsd.conf.org so it is retained in case you goof up later and need to start modifying it from scratch.

14 ) edit this apcupsd file (I used vi; it is amazing that 12 years later, I could remember i(insert to type), [ESC] get back to cursor control, dd(delete line), w(write file), q(quit), but I did what was needed. Key changes I made to the file to work with attached USB APC Backup-XS 1300 LCD:

Code: Select all

#UPSCABLE smart
UPSCABLE usb
#UPSTYPE apcsmart
#DEVICE /dev/ttyS0
UPSTYPE usb

I also changed some of the timing parameters, but that's just a matter of choice.

15 ) the first time I tried starting the apcupsd daemon, it immediately failed. I went to look at the log in the director (per above) only to find the directory did not exist. I went through the apcupsd.conf file again to see where the various directories should be and made the ones it referenced that didn't currently exist (from within /opt directory):

Code: Select all

[/opt] # mkdir var
[/opt] # mkdir var/lock
[/opt] # mkdir var/log

16 ) start the apcupsd daemon: [/opt] # /opt/sbin/apcupsd &
This time it didn't immediately exit (yeah!) as it did when those directories didn't exist.

17 ) verify that it is still running (paranoid?)
[/opt/var/log] # ps -aux | fgrep apcupsd
19820 admin 748 S /opt/sbin/apcupsd
20088 admin 448 R fgrep apcupsd

18 ) see if it will talk to us:

Code: Select all

/opt/var/log] # apcaccess status
APC      : 001,038,0974
DATE     : Tue Jan 19 21:50:49 EST 2010
HOSTNAME : 219NAS
RELEASE  : 3.14.5
VERSION  : 3.14.5 (10 January 2009) unknown
UPSNAME  : 219NAS_APCBackup-XS1300LCD
CABLE    : USB Cable
MODEL    : Back-UPS XS 1300 LCD
UPSMODE  : Stand Alone
STARTTIME: Tue Jan 19 21:48:38 EST 2010
STATUS   : ONLINE
LINEV    : 119.0 Volts
LOADPCT  :  29.0 Percent Load Capacity
BCHARGE  : 100.0 Percent
TIMELEFT :  20.3 Minutes
MBATTCHG : 50 Percent
MINTIMEL : 5 Minutes
MAXTIME  : 120 Seconds
SENSE    : High
LOTRANS  : 088.0 Volts
HITRANS  : 136.0 Volts
ALARMDEL : Always
BATTV    : 26.9 Volts
LASTXFER : Unacceptable line voltage changes
NUMXFERS : 0
TONBATT  : 0 seconds
CUMONBATT: 0 seconds
XOFFBATT : N/A
SELFTEST : NO
STATFLAG : 0x07000008 Status Flag
MANDATE  : XXXX-XX-XX
SERIALNO : XXXXXXXXXXXX

And it is 3.14.5 (THANK YOU Don)

19 ) The only thing left to do on the NAS side is figure out how to start this daemon after restart without having to PuTTY in each time, and possibly dodge some problems with the disks not being ready when the script tries to run (my config keeps disks AES locked until I manually unlock them, so /opt won't be available on boot). Will dig into Don's reference guide tomorrow on this.

20 ) To install the client that will listen on the PC side, obtain it here: http://www.apcupsd.com/. Lots of good stuff there, including a manual. Basic changes that need to be made to the PC apcupsd.config file are:

Code: Select all

#UPSCABLE usb
UPSCABLE ether
#UPSTYPE usb
#DEVICE
UPSTYPE net
DEVICE xxx.xxx.xxx.xxx:3551 (xxx.xxx.xxx.xxx = IP of your NAS)

You'll find nice links for starting/stopping and editing the apcupsd.config file installed in the Start > Programs > Apcupsd section under WinXP.

At the moment, all seems to be working. I don't have time to run the 'pull the plug' test at the moment, but I'll do that in the next day or two and let you know of any unexpected surprises.

Thanks to Don for giving me the confidence to give this a try with an end product that was what I was looking for.

[Don]

Hi Brian,

Glad to be of assistance.

Check out this post http://forum.qnap.com/viewtopic.php?f=45&t=25058 on using autorun with encrypted volumes. I haven't verified that it works as I do not run encrypted volumes so cannot test it.

Don

[edrikk]

Great post!

I wonder why apcupsd is not running by default?
I just ran the program (not even through ipkg, but rather the old one QNap simply refuses to upgrade), and it's working! My PC can see the NAS (TS209).

Thanks again,

[schumaku]

I wonder why apcupsd is not running by default?

+1000

[2manycables]

Great post!
I wonder why apcupsd is not running by default?
I just ran the program (not even through ipkg, but rather the old one QNap simply refuses to upgrade), and it's working! My PC can see the NAS (TS209).

What surprised me most was that enabling the UPS through the web admin pages didn't start the apcupsd daemon. This suggests to me that that mechanism enabled in the web admin is talking to the UPS through some other vector. This is just supposition on my part, but as I mentioned above, I've explicitly disabled UPS support through the web admin pages before firing up either version of apcupsd. I haven't tested, but it is possible that previous problems mentioned in the forums (apcupsd not working, or not seeming to properly control the UPS) could have been due at least in part to conflicts between the two separate processes (web admin process, apcupsd) trying to govern what the UPS does.

[edrikk]

Great post!
I wonder why apcupsd is not running by default?
I just ran the program (not even through ipkg, but rather the old one QNap simply refuses to upgrade), and it's working! My PC can see the NAS (TS209).

What surprised me most was that enabling the UPS through the web admin pages didn't start the apcupsd daemon. This suggests to me that that mechanism enabled in the web admin is talking to the UPS through some other vector. This is just supposition on my part, but as I mentioned above, I've explicitly disabled UPS support through the web admin pages before firing up either version of apcupsd. I haven't tested, but it is possible that previous problems mentioned in the forums (apcupsd not working, or not seeming to properly control the UPS) could have been due at least in part to conflicts between the two separate processes (web admin process, apcupsd) trying to govern what the UPS does.

You know what they say? Don't make an assumption, because you're bound to make an @$$ of yourself...
That's where I come in... Generally I put in due-dilligence, however, I (much like yourself), have/had the "Enable UPS" item checked in the Admin pages, and thus assumed that apcupsd would be up... I never checked ps, because ... well... why would I... Until your post. Sigh. No wonder my PC couldn't see my UPS connected to my QNap via USB....


Also, I didn`t even disable the admin based item... Just ran the upsd alongside it... I`ll make another assumption (lol), that both software are cleanly enough written to not clobber one another... Besides, they are both just listening to SNMP messages... (I figure, one of the two could shut off the box before the other, and also, if it`s the apcd doing it, the restart on power-return probably won`t work)....

[2manycables]

Also, I didn`t even disable the admin based item... Just ran the upsd alongside it... I`ll make another assumption (lol), that both software are cleanly enough written to not clobber one another... Besides, they are both just listening to SNMP messages... (I figure, one of the two could shut off the box before the other, and also, if it`s the apcd doing it, the restart on power-return probably won`t work)....

This isn't my area, but I think the SNMP messages are limited to the UPSs that communicate directly over the network and are not applicable to the direct cabled (USB/serial) UPSs. In terms of the latter, I suppose if there is a single device driver that talks to the device over USB, and can gracefully talk to multiple processes (web admin UPS control, apcupsd) then the harmonious scenario you paint is plausible. On the other hand, if there are two processes/drivers that don't know about each other that are contending for the same USB connection, that has more potential to be problematic, including the dificult-to-reproduce scenario of working fine until they both happen to try try to use the USB port at the same time.

Your point about behavior on power-return is a good one to consider - I haven't looked at that. In my scenario I'm not using that as I want the NAS to stay off until I can confirm everything is back to a good state.

If you test, let me know (tip: put devices on line power but leave USB connection to UPS intact, that way you can test software/timing without stressing the UPS battery). I'm most likely going to stick with the voodoo equivalent of waving a rattle, wafting incense, and spinning the mouse three times in a clockwise circle by leaving the web admin UPS control disabled.

[2manycables]

Hmmm, just tried testing the newer version apcupsd (NAS, PC connected to line rather than UPS). The PC monitoring the apcupsd on the NAS saw the ON BATTERY event and shut down appropriately. The NAS, however, did not.

When I tried to reboot the PCs I hit a gotcha. Something wasn't right and the PC would shutdown faster than I could log in and disable the apcupsd service. I had to log on into safe mode and set the apcupsd service to manual before I could successfully boot under normal mode.

When I went over to the NAS and did an apcaccess status, the daemon showed status as 'SHUTTING DOWN' even though the NAS hadn't and wasn't shutting down and the UPS was back on power. Cycling power on UPS (on/off button, not cutting power) didn't resolve this. Stopping/starting the apcupsd daemon on the NAS did (status changed to ONLINE). Starting the apcupsd service on the PC after the NAS was back in normal mode then went fine. Looks like this isn't out of the woods just yet.

[Don]

It's been a while since I looked at how apcupsd works but if I remember correctly you have to create your own scripts for each power event you want to handle. Since yo are running the one from ipkg you will have to create your own scripts. You will have to look at the apcupsd documentation to determine where they go and if they need to be named something special.

[2manycables]

It's been a while since I looked at how apcupsd works but if I remember correctly you have to create your own scripts for each power event you want to handle. Since yo are running the one from ipkg you will have to create your own scripts. You will have to look at the apcupsd documentation to determine where they go and if they need to be named something special.

Yeah, that's where my digging has taken me. I'd been focusing on the ipkg apcupsd.conf file to see what was different and fixed it in terms of missing/different directories. That was enough to get the PC listening on the network to shutdown during a test, but not the NAS itself. This moring I started looking at the ipkg apccontrol script which is the main control script and have started running across more problems such as missing directories on the NAS. To my surprise I've also found a missing command. The script calls /sbin/shutdown and there is no such command (or files named shutdown) on the NAS. That's pretty clearly the reason why the ipkg version of apcupsd is shutting down the PCs on my network that are watching it, but not the NAS itself.

But I think I'm going to luck out. Since the 'old' version of apcupsd (/etc/apcupsd/) which came installed on the NAS did work, I'm going to compare its scripts with the ipkg scripts to map out/fix the differences (e.g., '/sbin/shutdown' in the ipkg script morphs into /sbin/poweroff on the NAS which seems to do a lot of checking/repairing if necessary prior to actually shutting down the NAS, so I see why /sbin/shutdown has been removed). Will hopefully slog through that in the next couple of hours and then see where we are.

Tedious going, but I can still taste victory ahead but my initial thoughts of 'it should only take me a couple of minutes to get this working' that I made when the QNAP box arrived at the door are fading.

[Don]

A week or two ago I asked the maintainers of the apcupsd optware feeds if they could update apcupsd to the current version. I'm happy to tell you that they have updated it. The version on the ipkg feeds, at least the x86 feeds, is Version: 3.14.8-1. I have not checked the ARM feed yet.

[2manycables]

A week or two ago I asked the maintainers of the apcupsd optware feeds if they could update apcupsd to the current version. I'm happy to tell you that they have updated it. The version on the ipkg feeds, at least the x86 feeds, is Version: 3.14.8-1. I have not checked the ARM feed yet.

That's great news, but as I've discovered, there is still a bit of tweaking that needs to be done to get that ipkg to work (at least the one prior to this one), though much of the effort was figuring out what was calling what and when (this forum, Don of course, and the apcupsd docs were a huge help there). In overview:

1) The ipkg apcupsd distribution itself needs some changes because the QNAP environment is somewhat different from what is expected in the scripts. The apccontrol had to be changed in a couple of areas. I took a look at what QNAP had done with their old version and tossed most of it (i.e., abandoning the attempt to 'abort' an already started shutdown by killing the poweroff processes if power comes back on - who knows what else would have been killed by that time and left the system cripled), while retaining only the things required (poweroff instead of shutdown, etc). The various scripts and config files also referenced some nonexistant directories that had to be created. All in all the ipkg distribution was probably 99% of the way there, but out of the box it would not work. I also removed the external control scripts that sit in the apcontrol directory and run when it is called with a matching event (e.g, commok event, and script of same name) since they were just shells that sent mail to root on events. I replaced notification functionality with calls to write_log in scripts as well as appending to the apcupsd.events file so I could watch program flow/events while debugging and have the NAS page me with the QNAP built-in standard web based notification capability that monitors the system log.

2) The NAS has a different way of handling communications with the USB based UPS which is accessed through a control script ups.sh and dependent scripts/processes. I edited the scripts to turn off what looks like the part that does the talking to the USB so that apcupsd doesn't step on it and call them from autorun.sh to do this. This was somewhat working in the dark, but so far the end result is functional.

3) For the small set of folks that use disk encryption and load the key manually, you have to call these things only after the disks are mounted. I got a version working using autorun.sh on /dev/mdx6 per Don's guide, but decided in the end to go with a trick pointed out in this thread http://forum.qnap.com/viewtopic.php?f=45&t=25058 and now call my autorun script from the 'start' section of /opt/Optware.sh (haven't investigated how it manages to not run before disks are mounted, an adventure for another day). The autorun.sh also has to clean-up flags/locks that the apcupsd processes may have left when calling for a shutdown.

4) to complicate things, I created a directory /share/MD0_DATA/Qboot and moved all the necessary applications and scripts (except Optware.sh) into it so that apcupsd will run even if I uninstall the Opware things, or install an updated ipkg for apcupsd that steps on things. This way I can quickly revert to a working environment if the new one requires similar tweaking.

In the end, with all of the above, I had to modify: apcupsd.conf, apcontrol, Optware.sh, usub_ups.sh, and ups.sh as well as add the autorun.sh to stop QNAP ups monitoring, start apcupsd monitoring, and clean-up lock/state files that might be left over after a reboot.

BUT ... finally, as of this afternoon, the UPS passed its tests with a call to each and every apccontrol event variant, as well as 'pull the plug' testing. And, per the original goal, my PC on the same UPS is dutifully following along over the network and shutting itself down too when needed. So, I can state from first hand experience that apcupsd does work on a QNAP NAS and, more importantly, on *my* QNAP NAS.