Re: [Nut-upsuser] This guy must be an idiot
On Wed, May 27, 2009 at 1:10 AM, Leslie Rhorer wrote: >OK, can someone tell me what utterly moronic thing I am doing wrong? > >I have two roughly identical Linux system running NUT, and one works > properly. The other almost does. The second system works well once > everything is up, but after booting, the system does not have connectivity > to the UPS. What do the logs say? > I have to manually run `upsdrvctl start backup`, > `/etc/init.d/nut start`, and `upsd` to get NUT working. Thereafter it works > fine, whether anyone is logged in or not. After a boot, however, I have to > log in and kick-start it again. Interesting, most systems are set up such that '/etc/init.d/nut start' will run upsdrvctl and upsd. To restart, does it suffice to only run '/etc/init.d/nut start'? >What am I missing? The S50nut symlink is in /etc/rc2.d, and both > systems are at runlevel 2. I set up the systems the very same way (as far > as I can remember or tell), except that one employs driver = tripplite_usb > in usb.conf and the other uses driver = usbhid-ups, plus the two have > different backup names. Otherwise, I think everything is the same. One thing you can do to catch any subtle differences is to tar up the /etc/nut directory on one machine, then extract it into /tmp on the other machine, and use 'diff -Naur /etc/nut /tmp/nut' or whatnot. -- - Charles Lepple ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] HP R3000XR battery charge levels?
On Thu, May 28, 2009 at 10:16:22PM +0200, Kjell Claesson wrote: > Hi again, > > Just a couple of values are bothering me here... hoping anyone else > > with an R3000XR can advise. > > > Nice to see that you got it running. > > > > battery.charge: 33.1 > > > battery.runtime: 442 > > > battery.voltage: 129.2 > > > > This may indicate a faulty battery in the pack. > You have 10x12volt, and it should go up to about 137 volt at > 100% charge. Ah, so it *is* a nominal-120V battery pack then, instead of the 24V pack in my SU1400. > Also the runtime estimated by the ups is only about 7 min (443 sec). > And that is low as it is only loaded to 37,5%. That should be a runtime > at about 13 min. Yeah, I'd expect that if it's only at 33% charge. > But one thing is bothering me: > >input.frequency.nominal: 60 > >input.transfer.boost.high: 12 > >input.voltage: 119.8 > >input.voltage.nominal: 120 > > The value for input.transfer.boost.high: is way out of range. > The value is not reported in the meter map > And you don't have any trim, high or low point. > It should look like this. > input.frequency.nominal: 50 > input.transfer.boost.high: 207 > input.transfer.high: 276 > input.transfer.low: 184 > input.transfer.trim.low: 243 > input.voltage: 229 > input.voltage.nominal: 230 > (this is from a PW5115) Comparing the two, yeah, that input.transfer.boost.high doesn't look right ... should probably be, what, around 97-102V? Several values there seem to be missing. > Also the serial number look strange. So I need to take look on the > driver. Yeah, I'd noticed the serial number looked funny. > > More to the point, though, is that battery charge level 33.1%? And if > > so, if the UPS is only at 37.5% load, why is the charge just sitting at > > 33.1%? Is that the expected output value, or a sign of a dying battery > > pack? > Think you have a dying battery pack. *nod* yeah, I had a bad feeling about that. The battery pack came with the UPS, both used. One of the reasons I badly wanted to get some UPS monitoring up was to be able to get some insight into the state of the battery pack. Still, even as it is it's better than no UPS. Looks like I can pick up a new set of batteries for about $160; that's better than I expected. Still probably have to wait until I have a job again though. -- Phil Stracchino, CDK#2 DoD#299792458 ICBM: 43.5607, -71.355 ala...@caerllewys.net ala...@metrocast.net p...@co.ordinate.org Renaissance Man, Unix ronin, Perl hacker, Free Stater It's not the years, it's the mileage. ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] HP R3000XR battery charge levels?
Hi again, > Just a couple of values are bothering me here... hoping anyone else > with an R3000XR can advise. > Nice to see that you got it running. > > battery.charge: 33.1 > > battery.runtime: 442 > > battery.voltage: 129.2 > > This may indicate a faulty battery in the pack. You have 10x12volt, and it should go up to about 137 volt at 100% charge. Also the runtime estimated by the ups is only about 7 min (443 sec). And that is low as it is only loaded to 37,5%. That should be a runtime at about 13 min. > > ups.load: 37.5 > > ups.power: 1080.5 > > ups.power.nominal: 2900 > This look OK. 1080.5 is about 37,5 % of 2900. > 129.2V battery voltage? Does the R3000 series use a line-voltage > battery pack to avoid the need for step-up/step-down transformers? No, it is the same battery-pack in the European 230 volt unit. But one thing is bothering me: >input.frequency.nominal: 60 >input.transfer.boost.high: 12 >input.voltage: 119.8 >input.voltage.nominal: 120 The value for input.transfer.boost.high: is way out of range. The value is not reported in the meter map And you don't have any trim, high or low point. It should look like this. input.frequency.nominal: 50 input.transfer.boost.high: 207 input.transfer.high: 276 input.transfer.low: 184 input.transfer.trim.low: 243 input.voltage: 229 input.voltage.nominal: 230 (this is from a PW5115) Also the serial number look strange. So I need to take look on the driver. > > More to the point, though, is that battery charge level 33.1%? And if > so, if the UPS is only at 37.5% load, why is the charge just sitting at > 33.1%? Is that the expected output value, or a sign of a dying battery > pack? Think you have a dying battery pack. /Kjell ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
[Nut-upsuser] HP R3000XR battery charge levels?
Just a couple of values are bothering me here... hoping anyone else with an R3000XR can advise. > battery.charge: 33.1 > battery.runtime: 442 > battery.voltage: 129.2 > ups.load: 37.5 > ups.power: 1080.5 > ups.power.nominal: 2900 129.2V battery voltage? Does the R3000 series use a line-voltage battery pack to avoid the need for step-up/step-down transformers? More to the point, though, is that battery charge level 33.1%? And if so, if the UPS is only at 37.5% load, why is the charge just sitting at 33.1%? Is that the expected output value, or a sign of a dying battery pack? -- Phil Stracchino, CDK#2 DoD#299792458 ICBM: 43.5607, -71.355 ala...@caerllewys.net ala...@metrocast.net p...@co.ordinate.org Renaissance Man, Unix ronin, Perl hacker, Free Stater It's not the years, it's the mileage. ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Nut and PowerWare 5115
Hi Arnaud, From: Arnaud Quette Sent: Wednesday, May 27, 2009 12:42 AM To: Greg Cc: Kjell Claesson ; nut-upsuser@lists.alioth.debian.org Subject: Re: [Nut-upsuser] Nut and PowerWare 5115 Greg, 2009/5/26 Arnaud Quette Hi Greg, 2009/5/21 Greg Hi Arnaud, Any luck with the latest subversion trunk? sorry for the lag... too many things, not enough time. I'm preparing a version with some more debug info, but I'm still puzzled with your issue. in the meantime, can you retry the debug test on your 9.04, ie export USB_DEBUG=3 && /lib/nut/bcmxcp_usb -u root -D -a PowerWare if you end up with "Can't set POWERWARE USB configuration", then we should have an msg from libusb like "could not set config..." with the exact errno... I missed to add that I'm also interested in this one: "unset USB_DEBUG && lsusb -d06da:0002 -v" on your 9.04. I can't find it back in the thread. Here is the output (the QNAP has the same output except the line 'idProduct 0x0002' is missing UPS on the QNAP) === Bus 002 Device 004: ID 06da:0002 Phoenixtec Power Co., Ltd UPS Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 1.10 bDeviceClass 0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 8 idVendor 0x06da Phoenixtec Power Co., Ltd idProduct 0x0002 UPS bcdDevice 1.00 iManufacturer 4 Powerware iProduct 24 Powerware UPS iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 34 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0x80 (Bus Powered) MaxPower 60mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 0 bInterfaceProtocol 0 iInterface 0 ** UNRECOGNIZED: 09 21 00 01 00 01 22 00 00 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0008 1x 8 bytes bInterval 20 Device Status: 0x (Bus Powered) === @Kjell: do you see anything that could lead to that kind of "regression"? I'm not sure that it's on our side though. @Greg: can you fill the following and perhaps do some more testing (note that you only need to exec the driver): - is 2.2.2 working on 9.04? (simply get the source, configure using the instructions at the bottom of this mail and then compile as usual) I didn't have much luck after compiling the driver as upsdrvctl was missing. So I just installed the .deb file from the repository. yes 2.2.2 works on 9.04. (upsdrvctl and bcmxcp_usb) 2.2.2 also works on 8.10 (upsdrvctl and bcmxcp_usb) - is 2.4.1 working on 8.10? no 2.4.1 does not work on 8.10. (upsdrvctl loads and returns to command prompt, does not display UPS firmware version etc, bcmxcp_usb works) no 2.4.1 does not work on 9.04. (upsdrvctl loads and returns to command prompt, does not display UPS firmware version etc, bcmxcp_usb works) So it looks like for me 2.4.1 is broken on 8.10 and 9.04. Running 'upsdrvctl start' does not return any errors or display the firmware version. Running 'upsdrvctl start' on 2.2.2 displays the firmware version. When running bcmxcp_usb on 9.04. upsmon is then able to pick up the UPS driver as running. It seems to be some issue with upsdrvcrl. My kernel on 9.04 is Linux Ubuntu9 2.6.28-11-generic #42-Ubuntu SMP Fri Apr 17 01:57:59 UTC 2009 i686 GNU/Linux === - I would need more tech info on your qnap (arch, linux version, libusb version, USB path ie /proc or /dev, verbose lsusb as told above) arch: arm linux version: Linux THEBOX 2.6.21.1-qnap #5 Wed Mar 18 15:19:23 CST 2009 armv5tejl unknown libusb version: 0.1.12 usb path: /proc lsusb: same as above except the line 'idProduct 0x0002' is missing UPS on the QNAP. * configure line -- configure --prefix=/usr \ --exec-prefix=/ \ --sysconfdir=/etc/nut \ --mandir=/usr/share/man \ --libdir=/lib \ --includedir=/usr/include \ --without-all \ --enable-static \ --with-statepath=/var/run/nut \ --with-altpidpath=/var/run/nut \ --with-drvpath=/lib/nut \ --with-pidpath=/var/run/nut \ --datadir=/usr/share/nut \ --with-pkgconfig-dir=/usr/lib/pkgconfig \ --with-user=nut --with-group=nut __ Information from ESET Smart Security, version of virus signature database 4109 (20090527) __ The message was checked by ESET Smart Security. http://www.eset.com ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Nut and PowerWare 5115
Hi Arnaud, From: Arnaud Quette Sent: Tuesday, May 26, 2009 11:53 PM To: Greg Cc: Kjell Claesson ; nut-upsuser@lists.alioth.debian.org Subject: Re: [Nut-upsuser] Nut and PowerWare 5115 Hi Greg, 2009/5/21 Greg Hi Arnaud, Any luck with the latest subversion trunk? sorry for the lag... too many things, not enough time. I'm preparing a version with some more debug info, but I'm still puzzled with your issue. in the meantime, can you retry the debug test on your 9.04, ie export USB_DEBUG=3 && /lib/nut/bcmxcp_usb -u root -D -a PowerWare if you end up with "Can't set POWERWARE USB configuration", then we should have an msg from libusb like "could not set config..." with the exact errno... I'll then ping you for the updated driver. Running the above on both 8.10 and 9.04 gives the following output. The command prompt is not returned. bcmxcp_usb keeps running - r...@ubuntu9:~# export USB_DEBUG=3 && /lib/nut/bcmxcp_usb -u root - -a PowerWare Network UPS Tools - BCMXCP UPS driver 0.21 (2.4.1) USB communication subdriver 0.17 debug level is '4' usb_set_debug: Setting debugging level to 3 (on) usb_os_init: Found USB VFS at /dev/bus/usb usb_os_find_busses: Found 001 usb_os_find_busses: Found 002 usb_os_find_devices: Found 001 on 001 usb_os_find_devices: Found 004 on 002 skipped 1 class/vendor specific interface descriptors usb_os_find_devices: Found 002 on 002 usb_os_find_devices: Found 001 on 002 error obtaining child information: Inappropriate ioctl for device Length of meter map: 81 Index Offset Format NUT 0021 f0 None 0023 0004 f0 ups.power 0027 0008 52 output.frequency 0028 0012 52 input.frequency 0033 0016 52 battery.voltage 0034 0020 f0 battery.charge 0035 0024 e2 battery.runtime 0056 0028 f0 input.voltage 0059 0032 f0 None 0062 0036 f0 ambient.temperature 0065 0040 41 output.current 0068 0044 41 output.current.nominal 0071 0048 f0 None 0078 0052 f0 output.voltage Length of alarm map: 27 Index Alarm Supported -001 INVERTER_AC_OVER_VOLTAGE No -001 INVERTER_AC_UNDER_VOLTAGE No -001 INVERTER_OVER_OR_UNDER_FREQ No -001 BYPASS_AC_OVER_VOLTAGE No -001 BYPASS_AC_UNDER_VOLTAGE No -001 BYPASS_OVER_OR_UNDER_FREQ No INPUT_AC_OVER_VOLTAGE Yes 0001 INPUT_AC_UNDER_VOLTAGE Yes 0002 INPUT_UNDER_OR_OVER_FREQ Yes -001 OUTPUT_OVER_VOLTAGE No -001 OUTPUT_UNDER_VOLTAGE No -001 OUTPUT_UNDER_OR_OVER_FREQ No -001 REMOTE_EMERGENCY_PWR_OFF No -001 REMOTE_GO_TO_BYPASS No -001 BUILDING_ALARM_6 No -001 BUILDING_ALARM_5 No -001 BUILDING_ALARM_4 No -001 BUILDING_ALARM_3 No -001 BUILDING_ALARM_2 No -001 BUILDING_ALARM_1 No -001 STATIC_SWITCH_OVER_TEMP No -001 CHARGER_OVER_TEMP No -001 CHARGER_LOGIC_PWR_FAIL No -001 CHARGER_OVER_VOLTAGE_OR_CURRENT No -001 INVERTER_OVER_TEMP No 0003 OUTPUT_OVERLOAD Yes -001 RECTIFIER_INPUT_OVER_CURRENT No -001 INVERTER_OUTPUT_OVER_CURRENT No -001 DC_LINK_OVER_VOLTAGE No -001 DC_LINK_UNDER_VOLTAGE No -001 RECTIFIER_FAILED No 0004 INVERTER_FAULT Yes -001 BATTERY_CONNECTOR_FAIL No -001 BYPASS_BREAKER_FAIL No 0005 CHARGER_FAIL Yes -001 RAMP_UP_FAILED No -001 STATIC_SWITCH_FAILED No -001 ANALOG_AD_REF_FAIL No -001 BYPASS_UNCALIBRATED No -001 RECTIFIER_UNCALIBRATED No -001 OUTPUT_UNCALIBRATED No -001 INVERTER_UNCALIBRATED No -001 DC_VOLT_UNCALIBRATED No -001 OUTPUT_CURRENT_UNCALIBRATED No -001 RECTIFIER_CURRENT_UNCALIBRATED No -001 BATTERY_CURRENT_UNCALIBRATED No -001 INVERTER_ON_OFF_STAT_FAIL No -001 BATTERY_CURRENT_LIMIT No -001 INVERTER_STARTUP_FAIL No -001 ANALOG_BOARD_AD_STAT_FAIL No -001 OUTPUT_CURRENT_OVER_100 No -001 BATTERY_GROUND_FAULT No -001 WAITING_FOR_CHARGER_SYNC No -001 NV_RAM_FAIL No -001 ANALOG_BOARD_AD_TIMEOUT No 0006 SHUTDOWN_IMMINENT Yes 0007 BATTERY_LOW Yes 0008 UTILITY_FAIL Yes -001 OUTPUT_SHORT_CIRCUIT No 0009 UTILITY_NOT_PRESENT Yes -001 FULL_TIME_CHARGING No -001 FAST_BYPASS_COMMAND No -001 AD_ERROR No -001 INTERNAL_COM_FAIL No -001 RECTIFIER_SELFTEST_FAIL No -001 RECTIFIER_EEPROM_FAIL No -001 RECTIFIER_EPROM_FAIL No -001 INPUT_LINE_VOLTAGE_LOSS No -001 BATTERY_DC_OVER_VOLTAGE No -001 POWER_SUPPLY_OVER_TEMP No -001 POWER_SUPPLY_FAIL No -001 POWER_SUPPLY_5V_FAIL No -001 POWER_SUPPLY_12V_FAIL No -001 HEATSINK_OVER_TEMP No -001 HEATSINK_TEMP_SENSOR_FAIL No -001 RECTIFIER_CURRENT_OVER_125 No -001 RECTIFIER_FAULT_INTERRUPT_FAIL No -001 RECTIFIER_POWER_CAPASITOR_FAIL No -001 INVERTER_PROGRAM_STACK_ERROR No -001 INVERTER_BOARD_SELFTEST_FAIL No -001 INVERTER_AD_SELFTEST_FAIL No -001 INVERTER_RAM_SELFTEST_FAIL No -001 NV_MEMORY_CHECKSUM_FAIL No -001 PROGRAM_CHECKSUM_FAIL No -001 INVERTER_CPU_SELFTEST_FAIL No -001 NETWORK_NOT_RESPONDING No -001 FRONT_PANEL_SELFTEST_FAIL No -001 NODE_EEPROM_VERIFICATION_ERROR No -001 OUTPUT_AC_OVER_VOLT_TEST_FAIL No -001 OUTPUT_DC_OVER_VOLTAGE No -001 INPUT_PHASE_ROTATION_ERROR No -001 INVERTER_RAMP_UP_TEST_FAILED No -001 INVERTER_OFF_COMMAND No -001 INVER
Re: [Nut-upsuser] APC Smart UPS 900i
Citeren Rene Bartsch : Command: "upsc su900i" -- snip --- battery.alarm.threshold: 0 battery.charge: 100.0 battery.charge.restart: 10 battery.date: 11/02/01 battery.runtime: 4440 battery.runtime.low: 120 battery.voltage: 27.67 battery.voltage.nominal: 024 driver.name: apcsmart driver.parameter.cable: 940-0024C driver.parameter.pollinterval: 2 driver.parameter.port: /dev/ttyUSB0 driver.version: 2.4.1 driver.version.internal: 2.03 input.frequency: 50.00 input.quality: FF input.sensitivity: H input.transfer.high: 253 input.transfer.low: 196 input.transfer.reason: O input.voltage: 229.4 input.voltage.maximum: 231.8 input.voltage.minimum: 229.4 output.voltage: 229.4 output.voltage.nominal: 225 ups.delay.shutdown: 180 ups.delay.start: 300 ups.id: UPS_IDEN ups.load: 006.2 ups.mfr: APC ups.mfr.date: 02/18/93 ups.serial: 00016325 ups.status: OL ups.temperature: 045.9 ups.test.interval: 0 ups.test.result: NO -- snap --- Many thanks for the fast help! :) Glad we could help you out here. I only see that I accidentally also removed the ups.model, so I'll fix that later today. This should be fairly easy to add back. Best regards, Arjen -- Please keep list traffic on the list ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] New NUT user with HP R3000XR problem
Citeren Brother Railgun of Reason : Oops, looking at the code I saw this isn't a warning, but a (fatal) error instead (this was not one of the most descriptive error messages I ever wrote). I now recall that this value is OS dependent, so you probably want/need to limit this in upsd.conf through the MAXCONN parameter (which in your case seems to be mandatory). Ah, ... yeah, that would have been better than patching the code, wouldn't it? *sheepish* I missed that parameter. I'll undo my patch and try using the maxconn param instead. As just mentioned, my studies appear to indicate that this is a tunable kernel parameter which, on Solaris, defaults out-of-the-box to 256. It is. I'm not quite sure what would be the better thing to do in case the (default) MAXCONN value is too high: 1) Bail out with a more descriptive error message 2) Adjust the number of connections to the maximum allowed (with message to syslog) I think it would be much more user friendly to do the latter, but opinions on this are welcomed. Given that this varies by OS *but* may be tunable, my inclination would be to adjust the connections to the max available if less than MAXCONN, emit a warning in syslog and on the console, and document in the sample upsd.conf that depending on OS this MAY be a tunable parameter. I think the safest we can do is, by default use the maximum number available (instead of fixing this to 1024). People would still be able to lower this value should they wish to (in order not to waste resources if this happens to be a very high value). But we *must* bail out (with a more descriptive error message) if people deliberately request a number higher than the system allows. You'll run into problems (and this may not be immediately after startup) if you exceed the maximum number of connections, so this must be fixed. The only way to guarantee this happens, is to refuse to start. [...] Ah, so the behavior is as *intended*, but the documentation has gotten out of step with the intent. I see. If this change was made for security reasons, perhaps this goal might be aided by adding a netblock ALLOW or ACCEPT directive? For example, with two subnets, I might specify: LISTEN 127.0.0.1 3493 ACCEPT 127.0.0.0/8 LISTEN 10.24.32.14 3493 ACCEPT 10.24.32.0/24 ACCEPT 10.24.33.0/24 upsd could simply refuse connections from outside the netblocks it had been told to ACCEPT, without doing any further authentication. For IP based access control, you'd better use a firewall which can do this much more efficiently than we ever can. We actually *removed* this and now use tcp_wrappers only for IP based *user* level access control. Best regards, Arjen -- Please keep list traffic on the list ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
