[Nut-upsuser] upsd/upsc, LISTEN and hostname resolution in master/slave

[Spike]

Hi,

I've been setting up a few Eatons 1500 USB in master/slave mode and run
into what I'm thinking is a hostname resolution problem.

Basically, to avoid hardcoding ips, I'd love to be able to add a LISTEN on
the lan's ip which has hostname, let's say, server1.local .

If I set up upsd.conf such as LISTEN server1.local 3493 what I end up with
is upsd listening on 127.0.0.1 . I'm guessing it gets this value from
/etc/hosts which overrides server1.local dns resolution.

So basically if I want it to listen on anything other than localhost I need
to hardcode an ip in upsd.conf or add a line to /etc/hosts, which is not
quite convenient if the computer gets its ip from dhcp.

What's more, it seems that upsc does the same thing, so if I have a line
such as:
MONITOR eaton@server1.local ... that will fail if I specified the external
ip. However this will succeed from the slave, because there's no
server1.local in /etc/hosts I'm guessing so the name resolves to the same
ip in the LISTEN.

Is this really the desired behavior? I can certainly work with it, but it
seems it'd be nice if it could work with dns resolution (at least client
side, the LISTEN statement I guess it's ok), but maybe I'm missing some
good reason why this would cause other issues.

best,

Spike
___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Eaton 1500 USB constant disconnections

[Spike]

Arno, thanks for taking the time to write back and no worries about lag,
we're all busy and I'm grateful there is a community to interact with to
begin with.

You're right - the problem went away once I actually configured nut. I
guess I was too "cautious" and when I saw the errors I thought something
was wrong with the usb connection and didn't try to get nut going assuming
it'd failed. Eventually debugging through systemd/udev I realized it was
indeed the device initiating a connection and found out about the pong from
the UPS.

thanks again and maybe worthwhile to have this documented somewhere,  not
sure, maybe the ML archive will work for that.

best,

Spike

On Tue, Mar 28, 2017 at 2:46 AM Arnaud Quette 
wrote:

>
> 2017-03-11 4:55 GMT+01:00 Spike :
>
> Hi,
>
>
> Hi Spike,
>
> sorry for the lag in answering, I was collecting the needed information.
>
> I have a eaton 1500 that connects to an Ubuntu Xenial box via USB. The UPS
> works, however exactly *ever 5 minutes* it disconnects and reconnects and I
> see this in syslog:
>
> Mar 10 19:50:32 spike kernel: usb 4-5: USB disconnect, device number 103
> Mar 10 19:50:33 spike kernel: usb 4-5: new low-speed USB device number 104
> using ohci-pci
> Mar 10 19:50:34 spike kernel: usb 4-5: New USB device found,
> idVendor=0463, idProduct=
> Mar 10 19:50:34 spike kernel: usb 4-5: New USB device strings: Mfr=1,
> Product=2, SerialNumber=4
> Mar 10 19:50:34 spike kernel: usb 4-5: Product: Ellipse PRO
> Mar 10 19:50:34 spike kernel: usb 4-5: Manufacturer: EATON
> Mar 10 19:50:34 spike kernel: usb 4-5: SerialNumber: P344G46HW9
> Mar 10 19:50:38 spike kernel: hid-generic 0003:0463:.1221:
> hiddev0,hidraw2: USB HID v1.10 Device [EATON Ellipse PRO] on
> usb-:00:12.0-5/input0
>
> does anybody have any clue why that's happening? besides spamming the logs
> I'm afraid that it may not reconnect at some point and/or fail when it's
> actually needed.
>
>
> this is a workaround implemented to avoid, under some specific conditions,
> a freeze of the USB communication.
> As far as I've been told, when there is an actual SW communication (such
> as with NUT) with requests and replies in the 5mn timeframe, this should
> not occur.
>
> Could you please:
> - confirm back that there is indeed a SW communication setup (NUT or
> UPower for example),
> - send me back the upsc output for this unit, including the serial number
> and firmware revision
>
> thanks and regards,
> Arno
> --
> Eaton Data Center Automation Solutions - Opensource Leader -
> http://42ity.org
> NUT (Network UPS Tools) Project Leader - http://www.networkupstools.org
> Debian Developer - http://www.debian.org
> Free Software Developer - http://arnaud.quette.fr
>
___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Is a timer a file?

[Roger Price]

Hi Arnaud,

On Wed, 22 Mar 2017, Arnaud Quette wrote:


  The technique is very general and is to send SIGUSR1/SIGUSR2 to the upsd 
daemon.  SIGUSR1 and SIGUSR2 are events just like ONBATT and ONLINE.
  The patch runs successfully on my opensuse 13.2 box, and solves my 
problem. In upssched.conf I now have declarations such as

     AT SIGUSR1 * CANCEL-TIMER shutdown-timer

  Will my patches be included in NUT?

I've quickly checked your 2 patches.  The solution seems to me not broad 
enough for injecting upstream. This works nice for a single device / UPS 
setup, but would not make it when there are more devices, as I get it.


True, I use SIGUSR1 and SIGUSR2 which do not allow a payload such as a UPS 
unit name.  That would require SIGQUEUE, which accepts integers and 
pointers to other values (such as UPS unit names), but a Bash script can 
only send integers with SIGQUEUE.  Sending pointers to UPS unit names 
would require a new C program.  This would be a good programming exercise, 
but no-one has asked for such a facility in NUT.


I suspect that only a small percentage of NUT users use upssched timers.

At first sight, I would more see something injecting into the PIPEFN 
fifo, i.e. acting the same way upsmon would when calling upssched with 
the upsname and the triggering event.
I think that this can be solved more easily with tools like socat or nc, 
sending the command directly to the pipe. For example, to cancel the 
timer "shutdown-timer" from the upssched-cmd script, you would:


   echo "CANCEL shutdown-timer" | socat - 
UNIX-CLIENT:/var/run/nut/upssched.pipe


What a hack! :-) Sure, it is possible to do clever things with such tools, 
but I wanted something that used the .conf files to express the 
configuration.


I also considered using a dummy UPS with a .dev script written and erased 
as needed by a Bash script.



Please tell me back if such solution would make it for you.


For the moment I will stick with my SIGUSR patches.

I also realize that the distributed sample configuration and scripts do 
not fully match the doc. I'll make another round of update for this, 
still on the same branch.


I would warmly welcome your help to complete the documentation, both 
with part of your patches that make sense,


I think the user documentation would benefit from an explanation that 
there are two possible approaches to NUT configuration: Simple/optimistic, 
without timers, and pessimistic with timers.  And then a complete, fully 
worked example of the NUT setup for the simplest usage based on OB and LB 
(no timers).  The example on my website covers the pessimistic (with 
timers) approach only.



along with the above solution if it's good too.


I would not recommend putting a technique based on socat/nc/netcat in the 
NUT user documentation, but perhaps under a heading such as "Debugging" it 
would be worth having it in the Developer Guide.


Best Regards, Roger
___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Eaton 1500 USB constant disconnections

[Arnaud Quette]

2017-03-11 4:55 GMT+01:00 Spike :

> Hi,
>

Hi Spike,

sorry for the lag in answering, I was collecting the needed information.

I have a eaton 1500 that connects to an Ubuntu Xenial box via USB. The UPS
> works, however exactly *ever 5 minutes* it disconnects and reconnects and I
> see this in syslog:
>
> Mar 10 19:50:32 spike kernel: usb 4-5: USB disconnect, device number 103
> Mar 10 19:50:33 spike kernel: usb 4-5: new low-speed USB device number 104
> using ohci-pci
> Mar 10 19:50:34 spike kernel: usb 4-5: New USB device found,
> idVendor=0463, idProduct=
> Mar 10 19:50:34 spike kernel: usb 4-5: New USB device strings: Mfr=1,
> Product=2, SerialNumber=4
> Mar 10 19:50:34 spike kernel: usb 4-5: Product: Ellipse PRO
> Mar 10 19:50:34 spike kernel: usb 4-5: Manufacturer: EATON
> Mar 10 19:50:34 spike kernel: usb 4-5: SerialNumber: P344G46HW9
> Mar 10 19:50:38 spike kernel: hid-generic 0003:0463:.1221:
> hiddev0,hidraw2: USB HID v1.10 Device [EATON Ellipse PRO] on
> usb-:00:12.0-5/input0
>
> does anybody have any clue why that's happening? besides spamming the logs
> I'm afraid that it may not reconnect at some point and/or fail when it's
> actually needed.
>

this is a workaround implemented to avoid, under some specific conditions,
a freeze of the USB communication.
As far as I've been told, when there is an actual SW communication (such as
with NUT) with requests and replies in the 5mn timeframe, this should not
occur.

Could you please:
- confirm back that there is indeed a SW communication setup (NUT or UPower
for example),
- send me back the upsc output for this unit, including the serial number
and firmware revision

thanks and regards,
Arno
-- 
Eaton Data Center Automation Solutions - Opensource Leader -
http://42ity.org
NUT (Network UPS Tools) Project Leader - http://www.networkupstools.org
Debian Developer - http://www.debian.org
Free Software Developer - http://arnaud.quette.fr
___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser