apcupsd antics

[penetrode]

Hi:

I just emerged apcupsd 3.10.9, and am facing the dreaded FATAL ERROR problem. I'm sure there's something I'm missing, but I'm stuck.

Two things to note first: This is an APC SmartUPS 750VXL that has both USB and serial ports; I am using the serial port with cable 94-0024C. Second, the machine has *two* ethernet adapters; eth0 has ip 192.168.0.2 and is set up with a crossover cable to another machine connected to the same UPS, which will be the slave.

Okay, first, here is my apcupsd.conf:

> UPSCABLE smart
> UPSTYPE smartups
> DEVICE /dev/ttyS0
> LOCKFILE /var/lock
> ONBATTERYDELAY 6
> BATTERYLEVEL 5
> MINUTES 3
> TIMEOUT 0
> ANNOY 300
> ANNOYDELAY 60
> NOLOGON disable
> KILLDELAY 0
> NETSERVER on
> NISIP 192.168.0.2
> NISPORT 3551
> EVENTSFILE /var/log/apcupsd.events
> EVENTSFILEMAX 10
> UPSCLASS netmaster
> UPSMODE net
> NETTIME 100
> NETPORT 6666
> SLAVE 192.168.0.1
> STATTIME 0
> STATFILE /var/log/apcupsd.status
> LOGSTATS off
> DATATIME 0


Starting apcupsd seems to work fine:

> root@wopr:/etc/apcupsd# /etc/init.d/apcupsd start
> * Starting APC UPS daemon... [ ok ]
> root@wopr:/etc/apcupsd#


The process is running:

> root@wopr:/etc/apcupsd# ps fax | grep apc
> 2765 ? S 0:00 /usr/sbin/apcupsd
> 2770 ? S 0:00 \_ /usr/sbin/apcupsd
> 2771 ? S 0:00 \_ /usr/sbin/apcupsd
> 2772 ? S 0:00 \_ /usr/sbin/apcupsd
> root@wopr:/etc/apcupsd#


Here's what's in /var/log/messages:

> Jan 26 18:12:22 wopr apcupsd[2820]: Slave connection failed Connection refused! Down slave 0
> Jan 26 18:13:04 wopr apcupsd[2829]: NIS server startup succeeded
> Jan 26 18:13:04 wopr apcupsd[2820]: apcupsd 3.10.9 (31 December 2003) gentoo startup succeeded


I'm not concerned about the slave error because I don't yet have the slave running (the problem happens even in standalone mode).

And, it also appears to be listening:

> root@wopr:/etc/apcupsd# netstat -a
> Active Internet connections (servers and established)
> Proto Recv-Q Send-Q Local Address Foreign Address State
> tcp 0 0 *:ssh *:* LISTEN
> tcp 0 0 192.168.0.2:3551 *:* LISTEN
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> tcp 0 0 wopr.vodacomm.ca:ssh 192.168.1.10:47916 ESTABLISHED
> udp 0 0 wopr.vodacomm.ca:ntp *:*
> udp 0 0 192.168.0.2:ntp *:*
> udp 0 0 localhost:ntp *:*
> udp 0 0 *:ntp *:*
> Active UNIX domain sockets (servers and established)
> Proto RefCnt Flags Type State I-Node Path
> unix 2 [ ACC ] STREAM LISTENING 12150 /dev/log
> unix 3 [ ] STREAM CONNECTED 206869 /dev/log
> unix 3 [ ] STREAM CONNECTED 206868
> unix 3 [ ] STREAM CONNECTED 12230 /dev/log
> unix 3 [ ] STREAM CONNECTED 12228
> unix 3 [ ] STREAM CONNECTED 2399
> unix 3 [ ] STREAM CONNECTED 2398
> unix 2 [ ] STREAM CONNECTED 2216
> root@wopr:/etc/apcupsd#



Just for further reference, here are my routes and the corresponding network connection:

> root@wopr:/etc/apcupsd# ifconfig eth0
> eth0 Link encap:Ethernet HWaddr 00:07:E9:39:24:30
> inet addr:192.168.0.2 Bcast:192.168.0.255 Mask:255.255.255.0
> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> RX packets:24 errors:0 dropped:0 overruns:0 frame:0
> TX packets:24 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:1000
> RX bytes:1536 (1.5 Kb) TX bytes:1676 (1.6 Kb)
> Interrupt:17 Base address:0xb400 Memory:e3800000-e3820000
>
> root@wopr:/etc/apcupsd# route
> Kernel IP routing table
> Destination Gateway Genmask Flags Metric Ref Use Iface
> 192.168.1.0 * 255.255.255.0 U 0 0 0 eth1
> 192.168.0.0 * 255.255.255.0 U 0 0 0 eth0
> loopback localhost 255.0.0.0 UG 0 0 0 lo
> default 192.168.1.1 0.0.0.0 UG 1 0 0 eth1
> root@wopr:/etc/apcupsd#


Everything looks kosher, so *why*, when I try to access the daemon, this happens?

> root@wopr:/etc/apcupsd# apcaccess status
> FATAL ERROR in apcaccess.c at line 278
> tcp_open: cannot connect to server localhost on port 3551.
> ERR=Connection refused
> root@wopr:/etc/apcupsd#


HALP

[whiskeypriest]

Greetings, all...long-time lurker, first-time poster. Love the distribution, etc.

I'm bumping this as I've experienced a similar issue with apcupsd 3.10.9; while I can get apcaccess and multimon.cgi to respond properly by setting NISIP=0.0.0.0 or 127.0.0.1, entering either a specific host IP or subnet yields the same error that penetrode describes. While I'm not horribly concerned with this at the moment, I'd feel much better if I could lock this down to a specific host IP/subnet...

While we're on the topic, I've also been unable to force a shutdown while testing the UPS (APC Back-UPS CS350, USB cable). I get all the wall messages I could possibly want, and communication between the UPS and my system is good (i.e. it acknowledges UPS battery, power restored, etc). Unfortunately, when I do a tail -f of /var/log/messages I see that the daemon is denied permission when it attempts to initiate a system shutdown (though it cancels these non-existent shutdowns just fine when I reconnect the power). This seems odd to me as apcupsd runs as root...something to do with the fact that I was testing this functionality in a console window under KDE perhaps?

I'll be happy to post more specs/logs/whatever on request, but I think I'm just missing something obvious or Gentoo-specific...

[whiskeypriest]

Well, that’s what I get for being lazy. Apparently, apcupsd’s inability to shutdown the system stemmed from the fact I hadn’t built the following into my kernel:

Code: Select all

[*]   Preliminary USB device filesystem

I had noticed a few of the USB subsystem tests “didn’t seem to apply” to my installation the first time around; figured I was alright since I had established communication with the UPS. Shame on me.

As penance, I’ll be posting a HOWTO on apcupsd with USB support to the Documentation, Tips & Tricks forum (since I’ve now got everything running to my satisfaction). Look for it sometime in the near future.

As for the nagging NISIP question, I finally dropped it after finding this from the man himself. See the second paragraph. I never was able to get this to bind to a specific address, subnet, or anything else…I’ve simply commented it out in apcupsd.conf and been happy ever since. If anyone has had any luck implementing this feature as-advertised, I’d be interested in hearing about it…