I have the "NETSERVER=off" line in the /etc/apcupsd/apcupsd.conf file. However, when I use the "/usr/sbin/apcaccess status" command, I get: FATAL ERROR in apcaccess.c at line 278 tcp_open: cannot connect to server localhost on port 3551. ERR=Connection refused I also tried setting "NETSERVER=on", and I get the same problem. Apcupsd's documentation states that it should start the listening service by itself. Also, sometimes the documentation refers to "NETSTATUS" instead of "NETSERVER", so I tried with both: same result. Reproducible: Always Steps to Reproduce: apcupsd-3.10.5-r3
I can reproduce this bug over here. It's really annoying.
I can replicate the "NETSERVER off" error with sys-apps/apcupsd-3.10.5-r3 and sys-apps/apcupsd-3.10.5-r4. "NETSERVER on" works just fine however.
Okies, i look into this: You have to use NETSERVER on in your apcupsd.conf. With NETSERVER OFF this problem still occurs. The ebuild installs a new apcupsd.conf which has NETSERVER on into it. So i guess you just didn't update your apcupsd.conf as recommended. I'll also bump the ebuild to 3.10.6 as it runs great over here. Please report back if this solves your problem.
3.10.6 does solves the problem on my end. I did update my apcupsd.conf file back with 3.10.5, but I always set NETSERVER off since I didn't see the point. BTW, for others, apcupsd takes a couple of seconds to open it's port, so checking right after restarting it will yeild the same result. Give it about 10 seconds. After realising that, I thought maybe 3.10.5 was ok after all, as it didn't work right away so I emerged 3.10.6. Also, I put "NISIP 127.0.0.1" in my apcupsd.conf file since I'm the only one who will be using that. However, 3.10.6 now uses the -s switch for sendmail, which Postfix doesn't like. I created a new bug report (32471, with a patch) which includes this "-s" problem as well as bad headers when apcupsd is sending mail.
Good. Thanks for your help. I edited the 3.10.6 ebuild several time to make sure cgi's etc. get installed into the right location. (apache/apache2). Closing this bug now.
