Hi, I have had a long standing problem with NUT talking to 110V MGE UPSs on FreeBSD, I was recently investigating again and noticed that upsd seems overly noisy, eg.. May 5 03:50:36 egbert upsd[96662]: UPS [ups1] data is no longer stale May 5 03:50:36 egbert upsd[96662]: Data for UPS [ups1] is stale - check driver May 5 03:50:36 egbert upsd[96662]: UPS [ups1] data is no longer stale May 5 03:50:36 egbert upsd[96662]: Data for UPS [ups1] is stale - check driver May 5 03:50:39 egbert upsd[96662]: UPS [ups1] data is no longer stale May 5 03:50:46 egbert upsd[96662]: Data for UPS [ups1] is stale - check driver May 5 03:50:46 egbert upsd[96662]: UPS [ups1] data is no longer stale May 5 03:50:47 egbert upsd[96662]: Data for UPS [ups1] is stale - check driver May 5 03:50:47 egbert upsd[96662]: UPS [ups1] data is no longer stale May 5 03:50:47 egbert upsd[96662]: Data for UPS [ups1] is stale - check driver May 5 03:50:47 egbert upsd[96662]: UPS [ups1] data is no longer stale May 5 03:50:47 egbert upsd[96662]: Data for UPS [ups1] is stale - check driver May 5 03:50:50 egbert upsd[96662]: UPS [ups1] data is no longer stale ie 5 messages per second! MAXAGE is 15 seconds, IMO it should be at _least_ that time between complaints of staleness.. Am I misunderstanding what MAXAGE does? -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 188 bytes Desc: This is a digitally signed message part. URL: <http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20090505/21d209a5/attachment.pgp>
Hi Daniel, 2009/5/5 Daniel O'Connor <doconnor at gsoft.com.au>> Hi, > I have had a long standing problem with NUT talking to 110V MGE UPSs on > FreeBSD, I was recently investigating again and noticed that upsd seems > overly noisy, eg.. > > May 5 03:50:36 egbert upsd[96662]: UPS [ups1] data is no longer stale > May 5 03:50:36 egbert upsd[96662]: Data for UPS [ups1] is stale - check > driver > May 5 03:50:36 egbert upsd[96662]: UPS [ups1] data is no longer stale > May 5 03:50:36 egbert upsd[96662]: Data for UPS [ups1] is stale - check > driver > May 5 03:50:39 egbert upsd[96662]: UPS [ups1] data is no longer stale > May 5 03:50:46 egbert upsd[96662]: Data for UPS [ups1] is stale - check > driver > May 5 03:50:46 egbert upsd[96662]: UPS [ups1] data is no longer stale > May 5 03:50:47 egbert upsd[96662]: Data for UPS [ups1] is stale - check > driver > May 5 03:50:47 egbert upsd[96662]: UPS [ups1] data is no longer stale > May 5 03:50:47 egbert upsd[96662]: Data for UPS [ups1] is stale - check > driver > May 5 03:50:47 egbert upsd[96662]: UPS [ups1] data is no longer stale > May 5 03:50:47 egbert upsd[96662]: Data for UPS [ups1] is stale - check > driver > May 5 03:50:50 egbert upsd[96662]: UPS [ups1] data is no longer stale > > ie 5 messages per second! MAXAGE is 15 seconds, IMO it should be at _least_ > that time between complaints of staleness.. > > Am I misunderstanding what MAXAGE does?I think I've found something, but I would need an upsd debug output (level 3) to see what going on the state socket. A few more questions: - would you be able to test a patch? - what version of nut is running there? - which driver (I assumed mge-shut)? cheers, Arnaud -- Linux / Unix Expert R&D - Eaton - http://www.eaton.com/mgeops Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org/ Debian Developer - http://www.debian.org Free Software Developer - http://arnaud.quette.free.fr/ -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20090506/fa1c338f/attachment.htm>
Hi all, I have some notes on getting Nut working with Vmware (ESX3.5 in my case), including the necessary settings in the esx to give nut permissions to shutdown the virtual machines. My live setup includes two monitored UPS's, two ESX servers and a scheduled shutdown script to stop vm's. Would there be any interest in a rpm of this or these notes to post on the web site? Mark.
Citeren Daniel O'Connor <doconnor at gsoft.com.au>:> I have had a long standing problem with NUT talking to 110V MGE UPSs on > FreeBSD, I was recently investigating again and noticed that upsd seems > overly noisy, eg.. > > May 5 03:50:36 egbert upsd[96662]: UPS [ups1] data is no longer stale > May 5 03:50:36 egbert upsd[96662]: Data for UPS [ups1] is stale - > check driver > May 5 03:50:36 egbert upsd[96662]: UPS [ups1] data is no longer stale > May 5 03:50:36 egbert upsd[96662]: Data for UPS [ups1] is stale - > check driver > May 5 03:50:39 egbert upsd[96662]: UPS [ups1] data is no longer stale > May 5 03:50:46 egbert upsd[96662]: Data for UPS [ups1] is stale - > check driver > May 5 03:50:46 egbert upsd[96662]: UPS [ups1] data is no longer stale > May 5 03:50:47 egbert upsd[96662]: Data for UPS [ups1] is stale - > check driver > May 5 03:50:47 egbert upsd[96662]: UPS [ups1] data is no longer stale > May 5 03:50:47 egbert upsd[96662]: Data for UPS [ups1] is stale - > check driver > May 5 03:50:47 egbert upsd[96662]: UPS [ups1] data is no longer stale > May 5 03:50:47 egbert upsd[96662]: Data for UPS [ups1] is stale - > check driver > May 5 03:50:50 egbert upsd[96662]: UPS [ups1] data is no longer stale > > ie 5 messages per second! MAXAGE is 15 seconds, IMO it should be at _least_ > that time between complaints of staleness..This has nothing to do with MAXAGE. This is the driver that is complaining about a lost connection to the UPS. The server can't do anything about that and only relays what it gets from the driver. As Arnaud has already mentioned, running the driver with debug level 3 or higher will tell you the reason why the server is logging these lines. In retrospect, it would have been better if it made a difference between the driver reporting this, or that the connection to the driver socket would be lost.> Am I misunderstanding what MAXAGE does?Probably not. In the old days, the server would run into staleness problems for the driver socket if driver authors wouldn't call dstate_dataok() frequent enough for the server to be happy. Now that the server solicits a response from drivers (PING) at least twice before declaring them stale, this really doesn't happen anymore for most drivers. Some are still taking way too much time in upsdrv_updateinfo(), which might lead to similar problems. Best regards, Arjen -- Eindhoven - The Netherlands Key fingerprint - 66 4E 03 2C 9D B5 CB 9B 7A FE 7E C1 EE 88 BC 57
Citeren Daniel O'Connor <doconnor op gsoft.com.au>:> Note that I still have trouble starting mge-shut - 50+% of the time it > says "Unable to get Report Descriptor"Have you also tried the newmge-ups driver? Being based on the same core as the usbhid-ups (USB) driver, it may be a little more forgiving in case of timeouts (although I'm not very familiar with it's predecessor, mge-shut). The SHUT protocol is *very* verbose and uses a slow 2400 baud link, so you want to give it lots of time before giving up (reading a 1500+ bytes report descriptor will take more than 10 seconds). You may want to increase MAXAGE in upsd.conf to at least double that, to prevent PINGing the driver to death. Best regards, Arjen -- Please keep list traffic on the list
Citeren Arjen de Korte <nut+devel op de-korte.org>:>> Note that I still have trouble starting mge-shut - 50+% of the time it >> says "Unable to get Report Descriptor" > Have you also tried the newmge-ups driver?s/newmge-ups/newmge-shut/g Best regards, Arjen -- Please keep list traffic on the list