[Nut-upsuser] upsd/upsc, LISTEN and hostname resolution in master/slave
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
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?
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
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