Re: [Nut-upsuser] [Eaton 5S 1500] overvoltage shut down?
fwiw, in case somebody in the future stumbles on this thread, I finally got around to talk to a tech at Eaton and look again at our systems and it may have been a ground fault. What I did not know and it's not in the manuals, but which makes sense, is that the only condition under which those UPSs would shut themselves down like that is if they detected a ground fault/power on the neutral. Furthermore, I also confirmed that the unit does not store any kind of logs, so if any event was logged that would have been on the PC through the monitoring sw (nut didn't, but I suspect there was no event generated). best, Spike On Fri, Apr 7, 2017 at 4:28 PM Spike <sp...@drba.org> wrote: > Hello Charles, > > I've attached a dump below. There were no long entries on any of the > hosts, neither the one running standalone, nor the master/slave combo, > which is not too surprising, it was really fast: I saw the light flickering > in the room, almost like flash, and all those 3 systems went down. I first > heard the "click" of the ports being disabled, heard the systems shut down, > and then the louder click of the UPS turning itself off. Probably less than > 3secs in total. > > battery.charge: 100 > battery.charge.low: 20 > battery.runtime: 754 > battery.type: PbAc > device.mfr: EATON > device.model: Ellipse PRO 1500 > device.type: ups > driver.name: usbhid-ups > driver.parameter.pollfreq: 30 > driver.parameter.pollinterval: 2 > driver.parameter.port: auto > driver.version: 2.7.2 > driver.version.data: MGE HID 1.33 > driver.version.internal: 0.38 > input.frequency: 60.0 > input.transfer.high: 138 > input.transfer.low: 93 > input.voltage: 115.0 > input.voltage.extended: no > outlet.1.desc: PowerShare Outlet 1 > outlet.1.id: 2 > outlet.1.status: on > outlet.1.switchable: no > outlet.2.desc: PowerShare Outlet 2 > outlet.2.id: 3 > outlet.2.status: on > outlet.2.switchable: no > outlet.desc: Main Outlet > outlet.id: 1 > outlet.switchable: no > output.frequency: 60.0 > output.frequency.nominal: 60 > output.voltage: 114.0 > output.voltage.nominal: 115 > ups.beeper.status: enabled > ups.delay.shutdown: 20 > ups.delay.start: 30 > ups.firmware: 01.08.0016 > ups.load: 34 > ups.mfr: EATON > ups.model: Ellipse PRO 1500 > ups.power: 316 > ups.power.nominal: 1500 > ups.productid: > ups.realpower: 316 > ups.status: OL CHRG > ups.timer.shutdown: 0 > ups.timer.start: 0 > ups.vendorid: 0463 > > This is on ubuntu xenial. The servers have dual power supplies, total 4 > ports, plugged into the battery backups + surge protection ports on the > right hand side. Eco mode is disabled. > > thank you for your input, > > Spike > > On Fri, Apr 7, 2017 at 2:52 PM Charles Lepple <clep...@gmail.com> wrote: > >> >> last night we had what looked like a power spike and 3 machines plugged >> >> into 2 Eaton UPS went down instantly. I heard the click the UPS makes >> when >> >> it shuts the load on the ports and then shuts itself down (ie same >> thing if >> >> I simulate with upsmon -fsd). The machines instantly came back, there >> was no >> >> actual downtime, and the machine next to them which is not on the UPS >> never >> >> went down. >> >> >> >> This to me suggests some kind of overvoltage protection or something >> where >> >> the UPS decided to shut down the load, but I'm quite puzzled by it as >> I'd >> >> expect the UPS to actually shield the machines from it and certainly >> not >> >> turn something off brutally like that.. >> >> I'm going to CC Arnaud's work address just in case they have any >> additional information at Eaton, but for a variety of reasons, NUT is >> not very strong when it comes to post-mortem analysis of events. If >> the system running the NUT driver did not have a chance to log the >> event before power went down, it is difficult to ascertain what >> happened. >> >> Is there an "upsc" dump for these units in one of the other >> email/GitHub threads? (Feel free to redact all or part of the serial >> number.) I don't know of any particular combination of settings which >> might cause an immediate power-down for over-voltage, but it can't >> hurt to check. >> >> Arno: do these models keep an event log in EEPROM? Didn't see anything >> in the MGE OPS protocol library on the NUT website, but I haven't had >> a chance to poke around the Eaton website. >> >> -- >> - Charles Lepple >> > ___ 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 5S 1500] overvoltage shut down?
Hello Charles, I've attached a dump below. There were no long entries on any of the hosts, neither the one running standalone, nor the master/slave combo, which is not too surprising, it was really fast: I saw the light flickering in the room, almost like flash, and all those 3 systems went down. I first heard the "click" of the ports being disabled, heard the systems shut down, and then the louder click of the UPS turning itself off. Probably less than 3secs in total. battery.charge: 100 battery.charge.low: 20 battery.runtime: 754 battery.type: PbAc device.mfr: EATON device.model: Ellipse PRO 1500 device.type: ups driver.name: usbhid-ups driver.parameter.pollfreq: 30 driver.parameter.pollinterval: 2 driver.parameter.port: auto driver.version: 2.7.2 driver.version.data: MGE HID 1.33 driver.version.internal: 0.38 input.frequency: 60.0 input.transfer.high: 138 input.transfer.low: 93 input.voltage: 115.0 input.voltage.extended: no outlet.1.desc: PowerShare Outlet 1 outlet.1.id: 2 outlet.1.status: on outlet.1.switchable: no outlet.2.desc: PowerShare Outlet 2 outlet.2.id: 3 outlet.2.status: on outlet.2.switchable: no outlet.desc: Main Outlet outlet.id: 1 outlet.switchable: no output.frequency: 60.0 output.frequency.nominal: 60 output.voltage: 114.0 output.voltage.nominal: 115 ups.beeper.status: enabled ups.delay.shutdown: 20 ups.delay.start: 30 ups.firmware: 01.08.0016 ups.load: 34 ups.mfr: EATON ups.model: Ellipse PRO 1500 ups.power: 316 ups.power.nominal: 1500 ups.productid: ups.realpower: 316 ups.status: OL CHRG ups.timer.shutdown: 0 ups.timer.start: 0 ups.vendorid: 0463 This is on ubuntu xenial. The servers have dual power supplies, total 4 ports, plugged into the battery backups + surge protection ports on the right hand side. Eco mode is disabled. thank you for your input, Spike On Fri, Apr 7, 2017 at 2:52 PM Charles Lepple <clep...@gmail.com> wrote: > >> last night we had what looked like a power spike and 3 machines plugged > >> into 2 Eaton UPS went down instantly. I heard the click the UPS makes > when > >> it shuts the load on the ports and then shuts itself down (ie same > thing if > >> I simulate with upsmon -fsd). The machines instantly came back, there > was no > >> actual downtime, and the machine next to them which is not on the UPS > never > >> went down. > >> > >> This to me suggests some kind of overvoltage protection or something > where > >> the UPS decided to shut down the load, but I'm quite puzzled by it as > I'd > >> expect the UPS to actually shield the machines from it and certainly not > >> turn something off brutally like that.. > > I'm going to CC Arnaud's work address just in case they have any > additional information at Eaton, but for a variety of reasons, NUT is > not very strong when it comes to post-mortem analysis of events. If > the system running the NUT driver did not have a chance to log the > event before power went down, it is difficult to ascertain what > happened. > > Is there an "upsc" dump for these units in one of the other > email/GitHub threads? (Feel free to redact all or part of the serial > number.) I don't know of any particular combination of settings which > might cause an immediate power-down for over-voltage, but it can't > hurt to check. > > Arno: do these models keep an event log in EEPROM? Didn't see anything > in the MGE OPS protocol library on the NUT website, but I haven't had > a chance to poke around the Eaton website. > > -- > - Charles Lepple > ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
[Nut-upsuser] [Eaton 5S 1500] overvoltage shut down?
Dear all, maybe not strictly a NUT question but I can't imagine a better place to ask, hope that's ok. last night we had what looked like a power spike and 3 machines plugged into 2 Eaton UPS went down instantly. I heard the click the UPS makes when it shuts the load on the ports and then shuts itself down (ie same thing if I simulate with upsmon -fsd). The machines instantly came back, there was no actual downtime, and the machine next to them which is not on the UPS never went down. This to me suggests some kind of overvoltage protection or something where the UPS decided to shut down the load, but I'm quite puzzled by it as I'd expect the UPS to actually shield the machines from it and certainly not turn something off brutally like that.. has anybody seen stuff like that before? is this a faulty UPS? both units are new and from two different suppliers so I'm more leaning toward something I don't understand than faulty hw. thanks for any input, 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] how do you test (nagios) that upsmon is connected?
thank you all for your input. Roger, I'm a nut noob and only marginally understand the implementation (from your other email), but I really like the idea of a heartbeat and design wise it makes a lot of sense. I'll see if I can implement it some time soon. thank you, Spike On Sat, Apr 1, 2017 at 1:54 PM Roger Price <ro...@rogerprice.org> wrote: > On Sat, 1 Apr 2017, Stuart Gathman wrote: > > > On 04/01/2017 03:14 PM, Dan Craciun wrote: > >> On my Nagios monitoring system I use check_nut_plus (that in turn > >> calls upsc) to monitor the status (ups.status), load (ups.load), > >> battery charge (battery.charge) and runtime (battery.runtime). > >> > >> If these return "unknown", it means upsd is no longer monitoring the > >> UPS. As long as you get data, upsd is working. > >> > > That's great, but Spike wants to know whether *upsmon* is working. He > > already has a way to check that upsd is working. > > How about using a dummy ups to set up a regular end-to-end heart beat. > As long as the heart beats, there is no news, but if it stops, > upssched-cmd sends out an e-mail or other warning. > > In ups.conf, add > > [heartbeat] > driver = dummy-ups > port = heartbeat.dev > desc = "Dummy ups sends heart beat to upssched-cmd" > > In heartbeat.dev, write > > ups.status: REPLBATT > TIMER 300 > > In upsmon.conf, write > > NOTIFYFLAG REPLBATT SYSLOG+EXEC > > In upssched.conf, add > > # Heatbeat from dummy ups every 5 minutes, re-start 6 minute timer > AT REPLBATT heartbeat CANCEL-TIMER heatbeat-timer > AT REPLBATT heartbeat START-TIMER heatbeat-timer 360 > > In upssched-cmd, if heatbeat-timer completes, then send "UPS heatbeat > failure" message to sysadmin. > > If this works, let me know, and I will use it myself :-) > It would be nice to have a HEARTBEAT status instead of using REPLBATT. > > Roger > > ___ > Nut-upsuser mailing list > Nut-upsuser@lists.alioth.debian.org > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser > ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
[Nut-upsuser] how do you test (nagios) that upsmon is connected?
Dear all, I got nut going on one machine as standalone and on another 2 as master/slave and would like to add some checks to nagios to make sure that things are in order. Most of the checks I've seen out there use upsc to check the ups. This is a step forward compared to no monitoring, however as far as I can tell it doesn't really address what I think is a critical point: upsmon is actually monitoring the ups [and will shut down the box if needed]. I looked at the upsd and upsmon man pages, but can't see anything like a "status" command that will show me if the connection is healthy (I noticed that when I restart the daemons I get a log line saying "Communications with UPS eaton5s@127.0.0.1 established", but I can't seem to find a place to access that). I could in theory check if the port is in use/ESTABLISHED, lsof -i:3493, but it's not great. Is there any command I can run that will confirm if upsmon is correctly connected? thanks, 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] upsd/upsc, LISTEN and hostname resolution in master/slave
Manuel,
I very much appreciate you taking the time to share such depth of
experience, that makes a lot of sense and clearly things out very
thoroughly. I will amend my ansible common playbook to get rid of that line
and will test to see if I can find any problems elsewhere, but otherwise
that sounds like the best solution.
thanks again,
Spike
On Wed, Mar 29, 2017 at 12:11 PM Manuel Wolfshant <wo...@nobugconsulting.ro>
wrote:
> On 03/29/2017 06:35 PM, Spike wrote:
>
> thank you Arno, I'm with Manuel on the "IP address or hostname", maybe I
> didn't understand your previous explanation, but to me there's still a
> bigger issue/unclear behavior.
>
> Let's say I just installed ubuntu on a machine with hostname server1 and
> ip 192.168.0.1 . In /etc/hosts I end up with two lines (per
> https://www.debian.org/doc/manuals/debian-reference/ch05.en.html#s-net-dns
> ):
>
> 127.0.0.1 localhost
> 127.0.1.1 server1 server1.domain (notice the two entries, with and without
> domain)
>
> I then have bind configured on the network to resolve server1
> to 192.168.0.1
>
> If at this point I install NUT and set upsd.conf as a server and set the
> line such as:
>
> LISTEN server1.domain 3493
>
> I expect nut to listen on the local lan interface with ip 192.168.0.1 , ie
> I expect it to be equivalent to:
>
> LISTEN 192.168.0.1 3493
>
> But it's not, the latter will listen on that ip while the former will
> listen on 127.0.0.1.
>
> There is a slight misunderstanding here from your part.
> If nut ( or any other network daemon actually ) is configured to use a
> specific IP address ( as opposed to a hostname ) it can do ( and will do )
> a direct bind on that specific IP and things are done. On the other hand,
> if its configuration contains a hostname, it must pass that hostname to a
> resolver which in turn will provide the IP to use ( "man gethostbyname" for
> details ) .
> In your case, because /etc/nsswitch.conf contains ( by default ) a stanza
> saying:
> hosts: files dns
> glibc ( i.e. the resolver ) will look FIRST in /etc/hosts ( because of
> the "files" directive ) and since it gets a successful hit on that hostname
> it will pass on the corresponding IP ("127.0.1.1" for your case) to the
> daemon that asked for said hostname without even trying to interrogate the
> domain server. Therefore in your case nut will listen on 127.0.1.1. If and
> only if in /etc/hosts there is no entry for the queried hostname ( i.e. if
> you remove the "127.0.1.1 server1 server1.domain" line ) will the resolver
> ask the global name server ( following the "dns" directive from
> /etc/nsswitch.conf )
>
>
>
> If I want nut to only listen locally I would use 127.0.0.1 or localhost as
> in the examples on the nut's manual.
>
> right...
>
>
> This is my experience with configuring other daemons
>
> ALL daemons and any network application as well will follow the process I
> described earlier. One of the easiest way for so-called developers to test
> stuff that run on a web server without really uploading that to the real
> server is to configure their local machine to act as web server and add an
> entry like "127.0.0.1 webserver" in /etc/hosts. Any subsequent query for
> http://webserver on that machine will then hit their local webserver
> instead of the real one. I love to make fun of colleagues and add stuff
> like www.yahoo.com to a local server which replies with "you are not
> allowed to access yahoo.com while at work".
>
>
> and how I'd expect nut to behave, again this doesn't mean it's right, just
> trying to explain where my problems are coming from.
>
> nut will behave exactly as you expect it to once you ditch the offending (
> and useless ) line
>
>
>
> So, if we agree that that's how it's working and that the behavior is
> correct, the documentation should imho explicitly point that out that using
> the hostname is not sufficient to have nut listen on the external ip.
>
> The hostname is sufficient. You need to properly configure your machine.
> Either ditch that second line or reverse the order between "files" and
> "dns" ( which in turn will mean that you MUST add "localhost" to the global
> DNS zone otherwise you will face other very nasty problems due to your
> resolver never seeing a match for it !)
>
>
>
>
> Does that make sense? If we agree on that then the statement "Bind a
> listening port to the interface specified by its Internet address or name"
> is incorrect or at least unintuitive because I'd think of server1 to refer
> to the lan interface, not lo.
>
> The other problem is that n
Re: [Nut-upsuser] upsd/upsc, LISTEN and hostname resolution in master/slave
oh, my bad, actually, you even mentioned it, the other option would be to listen on 0.0.0.0 . I guess that'd work even tho it'd then be a good thing to have local firewall as you suggested. So maybe just have that in the docs too? I still think it'd be worth clarifying, if I got that right, that using _hostname_ is not sufficient to make it listen on any interface other than lo. On Wed, Mar 29, 2017 at 8:35 AM Spike <sp...@drba.org> wrote: > thank you Arno, I'm with Manuel on the "IP address or hostname", maybe I > didn't understand your previous explanation, but to me there's still a > bigger issue/unclear behavior. > > Let's say I just installed ubuntu on a machine with hostname server1 and > ip 192.168.0.1 . In /etc/hosts I end up with two lines (per > https://www.debian.org/doc/manuals/debian-reference/ch05.en.html#s-net-dns > ): > > 127.0.0.1 localhost > 127.0.1.1 server1 server1.domain (notice the two entries, with and without > domain) > > I then have bind configured on the network to resolve server1 > to 192.168.0.1 > > If at this point I install NUT and set upsd.conf as a server and set the > line such as: > > LISTEN server1.domain 3493 > > I expect nut to listen on the local lan interface with ip 192.168.0.1 , ie > I expect it to be equivalent to: > > LISTEN 192.168.0.1 3493 > > But it's not, the latter will listen on that ip while the former will > listen on 127.0.0.1. > > If I want nut to only listen locally I would use 127.0.0.1 or localhost as > in the examples on the nut's manual. This is my experience with configuring > other daemons and how I'd expect nut to behave, again this doesn't mean > it's right, just trying to explain where my problems are coming from. > > So, if we agree that that's how it's working and that the behavior is > correct, the documentation should imho explicitly point that out that using > the hostname is not sufficient to have nut listen on the external ip. > > Does that make sense? If we agree on that then the statement "Bind a > listening port to the interface specified by its Internet address or name" > is incorrect or at least unintuitive because I'd think of server1 to refer > to the lan interface, not lo. > > The other problem is that none of the fixes as far as I can see is > particularly clean/straightforward: > - adding a second line with the domain does not help because of what's in > /etc/hosts, so you still end up with NUT listening on localhost > - using an ip is not possible if DHCP is in the mix or just inconvenient > as it often is to hardcode ips in configs > - adding a line to /etc/hosts with the external ip would make it work, but > again auto generating that from dhcp with a hook script isn't > straightforward (not sure if there's a better way) > > what am I missing? > > thank you for your help, > > Spike > > > On Wed, Mar 29, 2017 at 4:57 AM Manuel Wolfshant <wo...@nobugconsulting.ro> > wrote: > > On 03/29/2017 02:28 PM, Arnaud Quette wrote: > > > > 2017-03-29 12:32 GMT+02:00 Arnaud Quette <arnaud.que...@gmail.com>: > > > > 2017-03-29 5:49 GMT+02:00 Spike <sp...@drba.org>: > (...) > > 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. > > > this is indeed undocumented (will fix it after this mail and a quick > lunch), but that works > > > I've clarified a bit: > > https://github.com/networkupstools/nut/commit/e83780337183d5369f892891df08775198231fe0 > > I'm interested in some feedback on whether this clarifies enough or not... > > I'd use "IP address or hostname" rather than "IP address or name" > ___ > Nut-upsuser mailing list > Nut-upsuser@lists.alioth.debian.org > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser > > ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] upsd/upsc, LISTEN and hostname resolution in master/slave
thank you Arno, I'm with Manuel on the "IP address or hostname", maybe I didn't understand your previous explanation, but to me there's still a bigger issue/unclear behavior. Let's say I just installed ubuntu on a machine with hostname server1 and ip 192.168.0.1 . In /etc/hosts I end up with two lines (per https://www.debian.org/doc/manuals/debian-reference/ch05.en.html#s-net-dns): 127.0.0.1 localhost 127.0.1.1 server1 server1.domain (notice the two entries, with and without domain) I then have bind configured on the network to resolve server1 to 192.168.0.1 If at this point I install NUT and set upsd.conf as a server and set the line such as: LISTEN server1.domain 3493 I expect nut to listen on the local lan interface with ip 192.168.0.1 , ie I expect it to be equivalent to: LISTEN 192.168.0.1 3493 But it's not, the latter will listen on that ip while the former will listen on 127.0.0.1. If I want nut to only listen locally I would use 127.0.0.1 or localhost as in the examples on the nut's manual. This is my experience with configuring other daemons and how I'd expect nut to behave, again this doesn't mean it's right, just trying to explain where my problems are coming from. So, if we agree that that's how it's working and that the behavior is correct, the documentation should imho explicitly point that out that using the hostname is not sufficient to have nut listen on the external ip. Does that make sense? If we agree on that then the statement "Bind a listening port to the interface specified by its Internet address or name" is incorrect or at least unintuitive because I'd think of server1 to refer to the lan interface, not lo. The other problem is that none of the fixes as far as I can see is particularly clean/straightforward: - adding a second line with the domain does not help because of what's in /etc/hosts, so you still end up with NUT listening on localhost - using an ip is not possible if DHCP is in the mix or just inconvenient as it often is to hardcode ips in configs - adding a line to /etc/hosts with the external ip would make it work, but again auto generating that from dhcp with a hook script isn't straightforward (not sure if there's a better way) what am I missing? thank you for your help, Spike On Wed, Mar 29, 2017 at 4:57 AM Manuel Wolfshant <wo...@nobugconsulting.ro> wrote: On 03/29/2017 02:28 PM, Arnaud Quette wrote: 2017-03-29 12:32 GMT+02:00 Arnaud Quette <arnaud.que...@gmail.com>: 2017-03-29 5:49 GMT+02:00 Spike <sp...@drba.org>: (...) 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. this is indeed undocumented (will fix it after this mail and a quick lunch), but that works I've clarified a bit: https://github.com/networkupstools/nut/commit/e83780337183d5369f892891df08775198231fe0 I'm interested in some feedback on whether this clarifies enough or not... I'd use "IP address or hostname" rather than "IP address or name" ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
[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 <arnaud.que...@gmail.com> wrote: > > 2017-03-11 4:55 GMT+01:00 Spike <sp...@drba.org>: > > 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
[Nut-upsuser] Eaton 1500 USB constant disconnections
Hi, 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. thanks, 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] unclear about expected shutdown behavior
Dear Charles and Roger, thank you for your help, once again I tried to google around but forgot to check launchpad's bugs. Indeed that was it and creating the script as mentioned in the second bug made it work: box was powered down, UPS was then shut down and it came back up along with the box a few secs later. Really smooth, thank you so much for such great piece of software. And yes, I have a launchpad account and have marked the bugs as effecting me. Happy holidays to everybody, Spike On Sat, Dec 24, 2016 at 6:00 AM Charles Lepple <clep...@gmail.com> wrote: > > > On Dec 24, 2016, at 3:14 AM, Roger Price <ro...@rogerprice.org> wrote: > > > > On Sat, 24 Dec 2016, Spike wrote: > > > >> ... from reading the docs it seems the UPS should power off, is that > the case? > > > > Yes, The UPS should be sent a "delayed shutdown" command, upsdrvctl > shutdown, to tell it to shut down _after_ the box. The amount of the delay > can be set in ups.conf. The UPS delayed shutdown turns off the output > sockets on the UPS. On some UPS's this gives an audible clunk. > > > >> The box correctly shuts down, but the UPS does not and, maybe as a > consequence, the box never came back on its own (I waited a few minutes). > > > > It looks as if the command upsdrvctl shutdown is not being executed. > Does the Ubuntu distribution of NUT include a script to do this? > > Roger, > > Ubuntu 16.04 ships the SysV init scripts for NUT that worked with previous > Ubuntu distributions, but it does not appear that the "powerdown" target > gets invoked anymore after the switch to systemd. > > Some relevant bugs: > > https://bugs.launchpad.net/ubuntu/+source/nut/+bug/1512603 > > https://bugs.launchpad.net/ubuntu/+source/nut/+bug/1603609 (includes > workaround) > > Spike, > > List subscription information is below. Please let us know if the > workaround mentioned in the second bug fixes things for you. If you have a > launchpad account, you can also mark the bug as affecting you. > > > ___ > > Nut-upsuser mailing list > > Nut-upsuser@lists.alioth.debian.org > > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser > > ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
[Nut-upsuser] unclear about expected shutdown behavior
Dear all, first post here and wanted to start by thanking everybody who made this possible. I've been reading the docs and setting up NUT from packages on ubuntu xenial. I have nut[-client,-server] installed, version 2.7.2-4ubuntu1. My UPS is an Eaton 5S 1500, which I picked from the list of supported devices. I've got it working and I can correctly query/monitor the UPS via USB etc. Following the docs I attempted to test a shutdown process (upsmon -c fsd) and this is where my question lies: from reading the docs it seems the UPS should power off, is that the case? The box correctly shuts down, but the UPS does not and, maybe as a consequence, the box never came back on its own (I waited a few minutes). Can anybody shed some light on what I should see as I force the shutdown sequence? Do you need me to provide more data? thanks all in advance, Spike ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
