Hello,
I've installed Nut (2.0.5) on RedHat a week ago, and upsmon seems to
generate false alarms every hour:
...
Jun 8 06:10:56 nutevalserver upsmon[2849]: UPS
usb-mge-evolution at localhost on line power
Jun 8 06:35:46 nutevalserver upsmon[2849]: UPS
usb-mge-evolution at localhost on battery
Jun 8 06:35:51 nutevalserver upsmon[2849]: UPS
usb-mge-evolution at localhost on line power
Jun 8 07:24:47 nutevalserver upsmon[2849]: UPS
usb-mge-evolution at localhost on battery
Jun 8 07:24:52 nutevalserver upsmon[2849]: UPS
usb-mge-evolution at localhost on line power
Jun 8 08:27:07 nutevalserver upsmon[2849]: UPS
usb-mge-evolution at localhost on battery
...
I increased the values for MAXAGE (upsd.conf, from 15 to 30) and
DEADTIME (upsmon.conf, from 15 to 25), and that reduced the false alerts
to every some hours. That's strange, I thought a problem with Maxage or
Deadtime would result in 'Stale information' messages instead of upsmon
believing the UPS is on battery....
Jun 12 13:03:21 nutevalserver upsmon[4020]: UPS
usb-mge-evolution at localhost on line power
Jun 12 21:30:38 nutevalserver upsmon[4020]: UPS
usb-mge-evolution at localhost on battery
Jun 12 21:30:48 nutevalserver upsmon[4020]: UPS
usb-mge-evolution at localhost on line power
Jun 13 04:22:49 nutevalserver upsmon[4020]: UPS
usb-mge-evolution at localhost on battery
Jun 13 04:22:59 nutevalserver upsmon[4020]: UPS
usb-mge-evolution at localhost on line power
Jun 13 09:39:59 nutevalserver upsmon[4020]: UPS
usb-mge-evolution at localhost on battery
*Jun 13 09:39:59 nutevalserver upsmon[4020]: UPS
usb-mge-evolution at localhost battery is low*
Here the situation got worse, upsmon thought the battery was low and
shut down the server. When I went to the server room almost immediately,
the UPS was fully charged, but the server had shut down. It looks like
either the driver (newhidups) or upsd is receiving wrong information.
I'm positive there are no electrical problems, as all the other servers
experience no problems...
The UPS is a MGE Evolution 650 connected by usb to the server. The nut
driver I'm using is newhidups and the configuration looks like this:
[usb-mge-evolution]
driver = newhidups
port = auto
vendorid = 0463
productid = ffff
desc = "MGE evolution ups,in de installatieruimte ter test"
Did anyone experience this before or has some advice?
Thanks,
Stijn Gruwier
**** DISCLAIMER ****
http://www.schaubroeck.be/maildisclaimer.htm
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20070613/5531be80/attachment.htm
> I've installed Nut (2.0.5) on RedHat a week ago, and upsmon seems to > generate false alarms every hour: > > ... > Jun 8 06:10:56 nutevalserver upsmon[2849]: UPS > usb-mge-evolution at localhost on line power > Jun 8 06:35:46 nutevalserver upsmon[2849]: UPS > usb-mge-evolution at localhost on battery > Jun 8 06:35:51 nutevalserver upsmon[2849]: UPS > usb-mge-evolution at localhost on line power > Jun 8 07:24:47 nutevalserver upsmon[2849]: UPS > usb-mge-evolution at localhost on battery > Jun 8 07:24:52 nutevalserver upsmon[2849]: UPS > usb-mge-evolution at localhost on line power > Jun 8 08:27:07 nutevalserver upsmon[2849]: UPS > usb-mge-evolution at localhost on battery > ...What makes you think these are false alarms?> I increased the values for MAXAGE (upsd.conf, from 15 to 30) and > DEADTIME (upsmon.conf, from 15 to 25), and that reduced the false alerts > to every some hours. That's strange, I thought a problem with Maxage or > Deadtime would result in 'Stale information' messages instead of upsmon > believing the UPS is on battery....State changes (as indicated above) are pushed by the driver to the server, which in turn will push it to the clients. There is nothing you can do about this by changing MAXAGE (this only changes the time between polls from the server to a driver that doesn't report any changes) or DEADTIME (that does essentially the same if the server is not reporting anything). If this seems to work, this is just a coincidence.> Jun 12 13:03:21 nutevalserver upsmon[4020]: UPS > usb-mge-evolution at localhost on line power > Jun 12 21:30:38 nutevalserver upsmon[4020]: UPS > usb-mge-evolution at localhost on battery > Jun 12 21:30:48 nutevalserver upsmon[4020]: UPS > usb-mge-evolution at localhost on line power > Jun 13 04:22:49 nutevalserver upsmon[4020]: UPS > usb-mge-evolution at localhost on battery > Jun 13 04:22:59 nutevalserver upsmon[4020]: UPS > usb-mge-evolution at localhost on line power > Jun 13 09:39:59 nutevalserver upsmon[4020]: UPS > usb-mge-evolution at localhost on battery > *Jun 13 09:39:59 nutevalserver upsmon[4020]: UPS > usb-mge-evolution at localhost battery is low* > > Here the situation got worse, upsmon thought the battery was low and > shut down the server.The battery probably *was* low at that time. If your UPS switches to battery serveral times per day for a couple of seconds, it will wear out your batteries quickly.> When I went to the server room almost immediately, > the UPS was fully charged, but the server had shut down.How did you determine the battery was fully charged? Did you execute a battery capacity test at that time? Or did the UPS indicate that the battery was full? If the battery is almost dead, it will seem to be fully charged pretty quickly after the return of mains power, yet the amount of charge it actually contains may be minimal. The only way to tell the battery charge, is by starting a battery test, either under software control or by pulling the plug on the UPS.> It looks like > either the driver (newhidups) or upsd is receiving wrong information.It may also mean that the mains to your UPS is browned out (bad cables, bad socket) or that it just senses that it is, while it actually isn't (trips on every mains glitch). For testing purposes, I keep one unit that does the latter. When the distribution transformer around the corner steps to another tap, it will always go to battery for couple of seconds. This usually happens a couple of times around six in the morning and around nine in the evening, every working day. When put to use, the average life expectancy of a good quality battery is about a year in that unit. In the production UPS next to it, they last about five years.> I'm positive there are no electrical problems, as all the other servers > experience no problems...That isn't a guarantee there are no problems. It wouldn't be the first outlet I've seen where the wiring wasn't attached properly or the cable was rotten. Best regards, Arjen -- Eindhoven - The Netherlands Key fingerprint - 66 4E 03 2C 9D B5 CB 9B 7A FE 7E C1 EE 88 BC 57
Hi, My colleague asked me to mail this info. It seems the problem only occures when using the usb interface. With the usb interface: *********************** [root at testserver /var/log]# /usr/local/ups/bin/upsc usb-mge-evolution at localhost battery.charge: 100 battery.charge.low: 20 battery.charge.restart: 0 battery.runtime: 1200 battery.type: PbAc battery.voltage: 13.0 driver.name: newhidups driver.parameter.port: auto driver.parameter.productid: ffff driver.parameter.vendorid: 0463 driver.version: 2.0.5 driver.version.data: MGE HID 1.0 driver.version.internal: 0.30 input.frequency: 50.0 input.transfer.boost.low: 184.0 input.transfer.high: 294.0 input.transfer.low: 160.0 input.transfer.trim.high: 265.0 input.voltage: 226.0 outlet.0.desc: Main Outlet outlet.0.id: 0 outlet.0.switchable: no outlet.1.autoswitch.charge.low: 0 outlet.1.delay.shutdown: 65535 outlet.1.delay.start: 3 outlet.1.desc: PowerShare Outlet 1 outlet.1.id: 1 outlet.1.status: on outlet.1.switchable: yes outlet.2.autoswitch.charge.low: 0 outlet.2.delay.shutdown: 65535 outlet.2.delay.start: 6 outlet.2.desc: PowerShare Outlet 2 outlet.2.id: 2 outlet.2.status: on outlet.2.switchable: yes output.current: 0.40 output.frequency: 50.0 output.voltage: 226.0 output.voltage.nominal: 24.0 ups.beeper.status: enabled ups.delay.shutdown: -1 ups.delay.start: -1 ups.load: 21 ups.mfr: MGE UPS SYSTEMS ups.model: Evolution 650 ups.power.nominal: 650 ups.serial: AV0G4602F ups.status: OL CHRG ups.test.interval: 604800 ups.test.result: Done and passed In the log file: **************** Broadcast message from nutups (Mon Jun 18 12:25:33 2007): UPS usb-mge-evolution at localhost on battery Jun 18 12:25:33 testserver upsmon[2872]: UPS usb-mge-evolution at localhost on battery Jun 18 12:25:33 testserver wall[361]: wall: user nutups broadcasted 1 lines (44 chars) Broadcast message from nutups (Mon Jun 18 12:25:43 2007): UPS usb-mge-evolution at localhost on line power Jun 18 12:25:43 testserver upsmon[2872]: UPS usb-mge-evolution at localhost on line power Jun 18 12:25:43 testserver wall[366]: wall: user nutups broadcasted 1 lines (47 chars) Broadcast message from nutups (Mon Jun 18 12:26:23 2007): UPS usb-mge-evolution at localhost on battery Jun 18 12:26:23 testserver upsmon[2872]: UPS usb-mge-evolution at localhost on battery Jun 18 12:26:23 testserver wall[370]: wall: user nutups broadcasted 1 lines (44 chars) Broadcast message from nutups (Mon Jun 18 12:26:33 2007): UPS usb-mge-evolution at localhost on line power Jun 18 12:26:33 testserver upsmon[2872]: UPS usb-mge-evolution at localhost on line power Broadcast message from nutups (Mon Jun 18 12:42:18 2007): UPS usb-mge-evolution at localhost on battery Jun 18 12:42:18 testserver upsmon[2872]: UPS usb-mge-evolution at localhost on battery Jun 18 12:42:18 testserver wall[385]: wall: user nutups broadcasted 1 lines (44 chars) Broadcast message from nutups (Mon Jun 18 12:42:28 2007): UPS usb-mge-evolution at localhost on line power Jun 18 12:42:28 testserver upsmon[2872]: UPS usb-mge-evolution at localhost on line power Jun 18 12:42:28 testserver wall[389]: wall: user nutups broadcasted 1 lines (47 chars) Broadcast message from nutups (Mon Jun 18 12:42:48 2007): UPS usb-mge-evolution at localhost battery is low Broadcast message from nutups (Mon Jun 18 12:42:48 2007): Executing automatic power-fail shutdown Broadcast message from nutups (Mon Jun 18 12:42:48 2007): UPS usb-mge-evolution at localhost on battery Broadcast message from nutups (Mon Jun 18 12:42:48 2007): Auto logout and shutdown proceeding With the serial interface: ************************** [root at testserver ~]# /usr/local/ups/bin/upsc serial-mge-evolution at localhost battery.charge: 100 battery.charge.low: 20 battery.runtime: 1200 driver.name: mge-shut driver.parameter.port: /dev/ttyS0 driver.version: 2.0.5 driver.version.internal: 0.66 input.frequency: 50 input.voltage: 226 outlet.0.desc: Main Outlet outlet.0.id: 0 outlet.0.switchable: 0 outlet.1.autoswitch.charge.low: 0 outlet.1.delay.shutdown: -1 outlet.1.delay.start: -1 outlet.1.desc: PowerShare Outlet 1 outlet.1.id: 1 outlet.1.switch: 1 outlet.1.switchable: 1 outlet.2.autoswitch.charge.low: 0 outlet.2.delay.shutdown: -1 outlet.2.delay.start: -1 outlet.2.desc: PowerShare Outlet 2 outlet.2.id: 2 outlet.2.switch: 1 outlet.2.switchable: 1 output.frequency: 50 output.voltage: 226 output.voltage.nominal: 24 ups.delay.shutdown: -1 ups.delay.start: -1 ups.load: 20 ups.mfr: MGE UPS SYSTEMS ups.model: Evolution 650 ups.power.nominal: 650 ups.serial: AV0G4602F ups.status: OL CHRG ups.test.result: Done and passed in the log file: **************** no shutdown or "on battery" messages> -------- Oorspronkelijk bericht -------- > Onderwerp: Re: [Nut-upsuser] false alerts/shutdown > Van: "Arjen de Korte" <nut+users at de-korte.org> > Datum: Vr, 15 juni, 2007 12:19 pm > Aan: "Stijn Gruwier" <sg at schaubroeck.be> > > > >>> What makes you think these are false alarms? >>> >> I have 2 reasons for believing these are false alarms: >> >> 1) The UPS doesn't beep and none of the status leds change when this >> occurs. I configured nut to page me for 'on battery' events, and while >> working in the server room I witnessed how NUT complained but the UPS >> didn't give a sign. In contrast, when it goes on battery because I >> pull the plug, it beeps, leds flash, ... >> > > How long it takes before a UPS starts to beep and whether or not it will > beep at all for glitches, is something that is rarely specified. Don't > count on it. > > >> 2) Three other servers (not backed up by ups) who share the same power >> distribution unit as the UPS are not affected. If these alarms are >> real, it means voltage drops to 160V. I thought that would shut a >> server down. Maybe you are right and a server can handle this for a >> few seconds? >> > > Not necessarily. When a UPS detects a mains glitch, it will usually go > to battery for a couple of seconds and then return. So even if the power > fails for just a couple of milliseconds, it will be on battery for a few > seconds. Most (if not all) servers will tolerate a complete loss of > input power for at least a full cycle (20 ms) and even longer than that > for brown outs. So the fact that other systems don't notice this, is no > indication either. > > [...] > > >> I'm almost sure the mains are OK since the building is less than 2 >> years old. >> > > That by itself tells nothing. Remember the recent deaths of patients in > an italian hospital where the builder swapped nitrous oxide and oxygen > lines? That department was brand new too, but sadly eight people died > before they found out. > > >> Also I connected the UPS to another socket across the room to no >> avail. I agree there might be electrical glitches, but wouldn't the >> UPS beep then? >> > > Not necessarily. Many will only start to beep when the mains is really > out, to prevent nagging people for each and every transient. > > To rule out problems with the USB port, could you try connecting this > UPS via a serial port and the 'mge-shut' driver? You might also run it > in debug mode, but this will probably result in huge amounts of data > since the protocol this UPS uses is very verbose. > > Best regards, Arjen > > > > > **** DISCLAIMER **** > http://www.schaubroeck.be/maildisclaimer.htm > >**** DISCLAIMER **** http://www.schaubroeck.be/maildisclaimer.htm -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20070618/b19551da/attachment.htm
Hi Stijn, all apologies for being so late to answer. As told to other, the APC|MGE merger, and now with Powerware entering the deal to buy MGE small units, makes me more busy than even... Back to your problem, I've identified and hunted the bug, thanks to Marc Recht? who provided the necessary information. I've just commited the fix into the Testing and trunk branches: http://boxster.ghz.cc/projects/nut/timeline ChangeSet 1000 (not yet available at the time of writing) This will be available in the next 2.2.0-pre and so in the final 2.2.0 version. If you are also interested in validating the fix, we can check for a delivery method (source tree, patch, package, ...) 2007/6/13, Stijn Gruwier <sg at schaubroeck.be>:> > Hello, > > I've installed Nut (2.0.5) on RedHat a week ago, and upsmon seems to > generate false alarms every hour: > > ... > Jun 8 06:10:56 nutevalserver upsmon[2849]: UPS usb-mge-evolution at localhost > on line power > Jun 8 06:35:46 nutevalserver upsmon[2849]: UPS usb-mge-evolution at localhost > on battery > Jun 8 06:35:51 nutevalserver upsmon[2849]: UPS usb-mge-evolution at localhost > on line power > Jun 8 07:24:47 nutevalserver upsmon[2849]: UPS usb-mge-evolution at localhost > on battery > Jun 8 07:24:52 nutevalserver upsmon[2849]: UPS usb-mge-evolution at localhost > on line power > Jun 8 08:27:07 nutevalserver upsmon[2849]: UPS usb-mge-evolution at localhost > on battery > ... > The UPS is a MGE Evolution 650 connected by usb to the server. The nut > driver I'm using is newhidups and the configuration looks like this: > [usb-mge-evolution] > driver = newhidups > port = auto > vendorid = 0463 > productid = ffff > desc = "MGE evolution ups,in de installatieruimte ter test" > > Did anyone experience this before or has some advice?thanks for your patience, Arnaud -- Linux / Unix Expert - MGE UPS SYSTEMS - R&D Dpt Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org/ Debian Developer - http://people.debian.org/~aquette/ OpenSource Developer - http://arnaud.quette.free.fr/
Hi Stijn, first, please keep the list cc'ed for info, since it can be interesting to other people... 2007/7/2, Stijn Gruwier <sg at schaubroeck.be>:> Hello Arnaud, > > Thanks for providing a fix so soon,thanks for being so lenient on the delay ;-)> I'd like to test/validate it. Could > you provide me with a new newhidups driver? Or some directions to > recompile it myself?simply get 2.2.0-pre2 (http://eu1.networkupstools.org/source.html) and compile as usual (that will be the quickest) (configure / make / make install). Note that the newhidups has been renamed to usbhid-ups, so modify your ups.conf accordingly, and launch upsd/upsmon/upsdrvctl. Once you are done with the test, and feedback, you can call "make uninstall" from the nut source dir. I'll wait for your feedback to release the final 2.2.0. Arnaud -- Free Software Developer - http://arnaud.quette.free.fr/ Debian Developer - http://people.debian.org/~aquette/ Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org/ Ubuntu Media Center (UMC) Project Leader - https://launchpad.net/~umc-team