Nut upsuser - Jan 2015 - Error: Connection failure: Connection refused

Hello list,

I am configuring NUT on a Dell workstation that is connected to an APC Back
UPS
Pro 1300, and I am running into an issue where starting everything manually
seems to be successful, but fails when using the init.d scripts.

The short story is that I get the following error when trying to check the
status of the UPS:
[root at mypc:/etc/nut]# upsc apc_pro1300 at localhost
Error: Connection failure: Connection refused

If I stop and then restart the service, I get "UPS apc_pro1300 at localhost
is
unavailable" errors walled to the logs and all consoles, but if I stop the
service (/etc/init.d/ups-monitor stop) and start the commands individually,
all
seems fine. I'm pretty sure I'm dealing with a permissions issue, but
everything
looks fine to me:
[root at mypc:/etc/nut]# ls -al /etc/nut
total 21
drwxr-xr-x   2 root nut  1024 Jan 30 07:56 .
drwxr-xr-x 126 root root 9216 Jan 30 13:24 ..
-rw-r-----   1 root nut  1543 Jan 30 09:18 nut.conf
-rw-r-----   1 root nut    91 Jan 30 09:11 ups.conf
-rw-r-----   1 root nut    66 Jan 30 09:11 upsd.conf
-rw-r-----   1 root nut   109 Jan 30 09:11 upsd.users
-rw-r-----   1 root nut   475 Jan 30 09:12 upsmon.conf
-rw-r-----   1 root nut  4075 Jan 30 09:13 upssched.conf

[root at mypc:/etc/nut]# ls -al /var/run/nut/
total 4
drwxrwx---  3 root nut   80 Jan 30 14:45 .
drwxr-xr-x 25 root root 820 Jan 30 13:29 ..
drwxrwx---  2 nut  nut   40 Jan 30 13:46 upssched
-rw-r--r--  1 root root   5 Jan 30 13:45 upsmon.pid

The long story:

Operating system is Debian Wheezy with NUT installed through aptitude. That
installs the nut meta-package which installs the nut-client, nut-server,
and the
libupsclient1 packages. Following the NUT User Guide for setting it up went
almost flawlessly:
[root at mypc:/etc/nut]# cat /etc/nut/ups.conf
[apc_pro1300]
   driver = usbhid-ups
   port   = auto
   desc   = "APC BackUPS Pro 1300"


[root at mypc:/etc/nut]# /sbin/upsdrvctl start
Network UPS Tools - UPS driver controller 2.6.4
Network UPS Tools - Generic HID driver 0.37 (2.6.4)
USB communication driver 0.32
Can't claim USB device [051d:0002]: could not detach kernel driver from
interface 0: Operation not permitted
Driver failed to start (exit status=1)

At this point I unplugged the UPS and plugged it into a different USP port,
but
that did not change the above. Figuring this was likely a udev problem, I
created the following /etc/udev/rules.d/52-nut-usbups.rules (based on an
example
on our database server, and changing the vendor and product id values):
[root at mypc:/etc/nut]# cat /etc/udev/rules.d/52-nut-usbups.rules
ACTION!="add|change", GOTO="nut-usbups_rules_end"
SUBSYSTEM=="usb_device", GOTO="nut-usbups_rules_real"
SUBSYSTEM=="usb", GOTO="nut-usbups_rules_real"
SUBSYSTEM!="usb", GOTO="nut-usbups_rules_end"

LABEL="nut-usbups_rules_real"

# APC - usbhid-ups
ATTR{idVendor}=="051d", ATTR{idProduct}=="0002",
MODE="664", GROUP="nut"

LABEL="nut-usbups_rules_end"


After that, the driver then starts:
[root at mypc:/etc/nut]# /sbin/upsdrvctl start
Network UPS Tools - UPS driver controller 2.6.4
Network UPS Tools - Generic HID driver 0.37 (2.6.4)
USB communication driver 0.32
Using subdriver: APC HID 0.95


continuing on, I edited /etc/nut/upsd.conf:
[root at mypc:/etc/nut]# cat /etc/nut/upsd.conf
LISTEN 127.0.0.1 3493
LISTEN ::1 3493


Then created /etc/nut/upsd.users:
[root at mypc:/etc/nut]# cat /etc/nut/upsd.users
[nut]
   password  = Password
   upsmon      master


And started the data server:
[root at mypc:/etc/nut]# /sbin/upsd
Network UPS Tools upsd 2.6.4
fopen /var/run/nut/upsd.pid: No such file or directory
listening on ::1 port 3493
listening on 127.0.0.1 port 3493
Connected to UPS [apc_pro1300]: usbhid-ups-apc_pro1300


Checking the status, things look good:
[root at mypc:/etc/nut]# /bin/upsc apc_pro1300 at localhost ups.status
OL


Looking at everything, all looked good, so I progressed to testing (the PC
is
not drawing it's power from the UPS at this point). I took the database
server's
upsmon.conf as an example and created my own:
[root at mypc:/etc/nut]# cat /etc/nut/upsmon.conf
FINALDELAY    15
HOSTSYNC      15
MONITOR       apc_pro1300 at localhost 1 nut Password master
NOTIFYCMD     /sbin/upssched
NOTIFYFLAG    ONLINE    SYSLOG+WALL+EXEC
NOTIFYFLAG    ONBATT    SYSLOG+WALL+EXEC
NOTIFYFLAG    LOWBATT   SYSLOG+WALL+EXEC
NOTIFYFLAG    COMMBAD   SYSLOG+EXEC
NOTIFYFLAG    COMMOK    SYSLOG+EXEC
NOTIFYFLAG    NOCOMM    SYSLOG+WALL+EXEC
POLLFREQ      10
POLLFREQALERT 10
POWERDOWNFLAG /tmp/killpower
RUN_AS_USER   nut
SHUTDOWNCMD   "/sbin/shutdown -h +0"


And started the monitor:
[root at mypc:/etc/nut]# /sbin/upsmon
Network UPS Tools upsmon 2.6.4
kill: No such process
UPS: apc_pro1300 at localhost (master) (power value 1)
Using power down flag file /tmp/killpower


Checking the log, that looks good too:
Jan 30 09:17:12 mypc usbhid-ups[6688]: Startup successful
Jan 30 09:20:37 mypc upsd[6979]: listening on ::1 port 3493
Jan 30 09:20:37 mypc upsd[6979]: listening on 127.0.0.1 port 3493
Jan 30 09:20:37 mypc upsd[6979]: Connected to UPS [apc_pro1300]:
usbhid-ups-apc_pro1300
Jan 30 09:20:37 mypc upsd[6980]: Startup successful
Jan 30 09:25:11 mypc upsmon[6987]: Startup successful
Jan 30 09:25:11 mypc upsd[6980]: User nut@::1 logged into UPS [apc_pro1300]


I then tested a shutdown with the -t flag, and then for real, and the
system did
shutdown, although the UPS did not power off:
sbin/upsmon -c fsd


But on boot up, I noticed the following:
Jan 30 09:53:44 mypc upsmon[3298]: Signal 15: exiting
Jan 30 09:53:44 mypc upsmon[3296]: upsmon parent: read
Jan 30 09:53:44 mypc upsmon[4839]: Startup successful
Jan 30 09:53:44 mypc upsmon[4841]: Login on UPS [apc_pro1300 at localhost]
failed - got [ERR ACCESS-DENIED]
Jan 30 09:57:45 mypc upsmon[4841]: Signal 15: exiting
Jan 30 09:57:45 mypc upsmon[4839]: upsmon parent: read
Jan 30 09:57:45 mypc upsmon[4881]: Startup successful
Jan 30 09:57:45 mypc upsd[3128]: User nut@::1 logged into UPS [apc_pro1300]


And I am unable to check the status of the UPS:
[root at mypc:/etc/nut]# upsc apc_pro1300 at localhost
Error: Connection failure: Connection refused


Again, if I stop the service and go through the steps to start everything
one at
a time, everything seems good and I can check the status.

Any useful information that I've left out is an oversight on my part, so
just
ask if additional info is needed. Any hints on my next steps would be
appreciated.

Regards,
Melvin
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20150130/cdacdd5c/attachment.html>

On Fri, 30 Jan 2015, Melvin Call wrote:
> [root at mypc:/etc/nut]# upsc apc_pro1300 at localhost
> Error: Connection failure: Connection refused
I had this error message.  In my case it was due to a network 
misconfiguration. Are you using TCP wrappers? If so, is this a missing 
entry in hosts.allow?

Roger Price

On 1/30/15, Roger Price <roger at rogerprice.org>
wrote:
> On Fri, 30 Jan 2015, Melvin Call wrote:
>
>> [root at mypc:/etc/nut]# upsc apc_pro1300 at localhost
>> Error: Connection failure: Connection refused
>
> I had this error message.  In my case it was due to a network
> misconfiguration. Are you using TCP wrappers? If so, is this a missing
> entry in hosts.allow?
>
> Roger Price
Hi Roger, and thanks for the reply.

After I shut the system down to plug it back into the UPS, and booted it back
up, everything is fine. I have rebooted several times during my trouble-shooting
and that had not resolved anything at all. I have no explanation because I can
not believe that the problem was caused all along by the lack of an electrical
connection between the systems.

I hate things like this. I spend several hours trying to figure this out, to no
avail. I send an email to a help list, only to have my problem inexplicably
resolve itself moments after hitting send. My apologies to the list for the
noise.

Regards,
Melvin

On Jan 30, 2015, at 4:22 PM, Melvin Call <melvincall979 at gmail.com>
wrote:
> At this point I unplugged the UPS and plugged it into a different USP port,
but
> that did not change the above. Figuring this was likely a udev problem, I
> created the following /etc/udev/rules.d/52-nut-usbups.rules (based on an
example
> on our database server, and changing the vendor and product id values):
You may want to rename this from 52- to 62-nut-usbups.rules, which will prevent
it from being masked by an earlier rules file.

Alternatively, you probably already have a similar file in /lib/udev/rules.d
that can be renamed. I thought there was a Debian bug about this, but here's
the equivalent Ubuntu bug database entry:
https://bugs.launchpad.net/ubuntu/+source/nut/+bug/1099947

-- 
Charles Lepple
clepple at gmail

On Jan 30, 2015, at 11:12 PM, Charles Lepple <clepple at gmail.com> wrote:
> On Jan 30, 2015, at 4:22 PM, Melvin Call <melvincall979 at gmail.com>
wrote:
> 
>> At this point I unplugged the UPS and plugged it into a different USP
port, but
>> that did not change the above. Figuring this was likely a udev problem,
I
>> created the following /etc/udev/rules.d/52-nut-usbups.rules (based on
an example
>> on our database server, and changing the vendor and product id values):
> 
> You may want to rename this from 52- to 62-nut-usbups.rules, which will
prevent it from being masked by an earlier rules file.
> 
> Alternatively, you probably already have a similar file in
/lib/udev/rules.d that can be renamed. I thought there was a Debian bug about
this, but here's the equivalent Ubuntu bug database entry:
https://bugs.launchpad.net/ubuntu/+source/nut/+bug/1099947
Well, Launchpad says it's
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=721600 which describes a
slightly different case, but the premise is the same.

At any rate, although your later email said that things were working, I suspect
that this might be a race condition that might come back later - hence the
suggestion to rename still stands.

-- 
Charles Lepple
clepple at gmail

On 1/30/15, Charles Lepple <clepple at gmail.com>
wrote:
> On Jan 30, 2015, at 4:22 PM, Melvin Call <melvincall979 at gmail.com>
wrote:
>
>> At this point I unplugged the UPS and plugged it into a different USP
>> port, but
>> that did not change the above. Figuring this was likely a udev problem,
I
>> created the following /etc/udev/rules.d/52-nut-usbups.rules (based on
an
>> example
>> on our database server, and changing the vendor and product id values):
>
> You may want to rename this from 52- to 62-nut-usbups.rules, which will
> prevent it from being masked by an earlier rules file.
>
> Alternatively, you probably already have a similar file in
/lib/udev/rules.d
> that can be renamed. I thought there was a Debian bug about this, but
here's
> the equivalent Ubuntu bug database entry:
> https://bugs.launchpad.net/ubuntu/+source/nut/+bug/1099947
>
> --
> Charles Lepple
> clepple at gmail
Thanks Charles, I will do that. There are only two other files in that
directory, 70-persistent-cd.rules and 70-persistent-net.rules.

In the meantime I'm fighting another similar problem. I'll start another
thread
on that though. Just not my weekend.

Regards,
Melvin