Re: [Nut-upsuser] NUT 2.0.5 and 2.2.2 hacking -- there is something to improve!
Citeren Kārlis Repsons [EMAIL PROTECTED]: Now *this* is useful! Do you have the full specification available? If possible, can you send it? Maybe other person will send. Given the total lack of support NUT gets from Cyberpower, I doubt it. Many users have already asked for this, but so far the response has invariably been that this is confidential information and that they can't release it. I'm actually quite surprised you have access to this information, unless you happen to be working for Cyberpower (or an affiliate). It seems to me that I've hit another dead end here, so I'm putting this on the back burner until I get some more information. In the mean time I'll spend my time on equipment from vendors that take supporting NUT seriously (by sending both documentation and hardware to test with). 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] Exclude COMMBAD status as a shutdown event?
Citeren Simon Meggle [EMAIL PROTECTED]: Ok obviously, in the default configuration upsmon decides to bring the system down on LB and COMMBAD (or, are there any other states?) . No, COMMBAD is just the first warning. You probably meant NOCOMM here. The system will be brought down in the following two states: 1) OB + LB 2) NOCOMM and last known state OB But how can I exclude the COMMBAD state from this behaviour? That's insane, so you don't. :-) If the last you heard from the master is that the UPS is on battery and communication is lost then, your only reasonable option is to shutdown. You can delay this (by changing DEADTIME in upsmon.conf), but question is, why you want to do that? My NUT masters are simple workstations. I don' t want to risk a complete ESX farm shutting down just because my NUT master failed... See above. 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] ubuntu 8.04 upssched CANCEL-TIMER ignored
Citeren Herwarth Heitmann herwa...@heitmann.nl: every two weeks my system shutsdown because my apc ups does a self test and nut is not picking up the cancel timer event. Do you have the EXEC flag set on the ONLINE event in 'upsmon.conf'? according to me all settings are correct. in my upssched-cmd script i execute a remote shutdown, because nut is running in a virtual machine and i want the script to shutdown all hosts in my esx environment. It usually helps if you mention which NUT version you're using. I don't have a clue which is shipped with Ubuntu 8.04 (and you may not be using their packaged version anyway). Since upsmon clearly sees the ONLINE event, we can rule out driver problems. I'm wondering where the logger output went by the way, it would be useful to see that. 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] Mustek drivers
Citeren Kjell Claesson kjell.claes...@epost.tidanet.se: [...] So the driver should support the mustek protocol. Maybe. It could also be speaking a dialect of the Megatec protocol and use 'QS\r' to query for the status. The new 'blazer_(ser|usb)' drivers will support that, the 'megatec(_usb)' doesn't. [...] Running a driver in debug mode might help to find communication problems, but if the UPS 'speaks' a different protocol, it most likely won't reveal anything. At best it will just echo the command back to let us know it doesn't understand it. If available, running the software that was bundled with the UPS on a Windows box while running a serial port sniffer, usually provides enough info about the protocol to see what driver should support it. 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] NUT SuSE Linux 11.0 USB ULTRA ULT33046 ups
Citeren Bill Blessing billy1...@gmail.com: The results of lsusb: Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 001 Device 002: ID 0d9f:0002 Powercom Co., Ltd Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub We don't have a driver for this device, so any attempts to make this work with the existing openSUSE packages are futile. The thread you were pointing to is for a different Powercom USB device, using a proprietary USB HID protocol. Nobody ever took the trouble of writing/completing a driver for it, so it still isn't supported (and may never be). Since your UPS has a different VID:PID combination, there is a remote chance that it is using another protocol. To check this out, create the following section in /etc/ups/ups.conf: [explore] driver = usbhid-ups port = auto vendorid = 0d9f productid = 0002 explore and post the output of the following command (run as 'root') here: /usr/lib/ups/driver/usbhid-ups -DDD -u root -a explore This will run until you stop it with ctrl-C. The first 10 seconds worth of output should be enough for now. If you're lucky it will speak HID PDC and we should be able to support it fairly quickly. However, if it is using something proprietary, this most likely will take much longer (if this ever happens). 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] Advice Partner PRPC650 - no serial device
Citeren Hai Zaar haiz...@gmail.com:
The current progress is like this:
With help from linux-hotplug guys
(http://thread.gmane.org/gmane.linux.hotplug.devel/13551) I've managed
to /dev/ttyUSB0 to be registered, but:
# /sbin/upsdrvctl start
Network UPS Tools - UPS driver controller 2.2.2
Network UPS Tools - PowerCom and similars protocol UPS driver $
Revision: 0.5 $ (2.2.2)
writing error
Question is, what is the syslog showing? The 'writing error' message
is awkward, but in the case of the powercom driver doesn't indicate
that the UPS wasn't detected or the driver didn't load properly. I
would like you to run the driver with debugging enabled to see what is
really happening:
powercom -D -a PRPC650 21
This will run until you kill it with ctrl-C. Post the first 30 seconds
worth of output after starting the driver and I'll take a look at it.
Note that I'm not the driver author however, so if this requires
digging deeper into the protocol, I'll step back.
# cat /etc/nut/ups.conf
[PRPC650]
driver = powercom
port = /dev/ttyUSB0
desc = Test
Trying with strace shows the following:
12369 open(/dev/ttyUSB0, O_RDWR|O_EXCL|O_NOCTTY|O_NONBLOCK) = 4
12369 flock(4, LOCK_EX|LOCK_NB) = 0
12369 ioctl(4, SNDCTL_TMR_TIMEBASE or TCGETS, {B1200 -opost -isig
-icanon -echo ...}) = 0
12369 ioctl(4, TCFLSH, 0) = 0
12369 ioctl(4, SNDCTL_TMR_TIMEBASE or TCGETS, {B1200 -opost -isig
-icanon -echo ...}) = 0
12369 ioctl(4, SNDCTL_TMR_START or TCSETS, {B1200 -opost -isig -icanon
-echo ...}) = 0
12369 ioctl(4, SNDCTL_TMR_TIMEBASE or TCGETS, {B1200 -opost -isig
-icanon -echo ...}) = 0
12369 ioctl(4, TIOCMBIC, [TIOCM_DTR]) = 0
12369 ioctl(4, TIOCMBIS, [TIOCM_RTS]) = 0
12369 write(4, \1..., 1) = -1 EAGAIN (Resource
temporarily unavailable)
12369 write(2, writing error\n..., 14) = 14
Any hint please?
It's too soon to run the driver through 'strace'. Unless you're trying
to diagnose communication problems, this is much too verbose to be
useful at this stage. The driver shouldn't mention the 'writing error'
message without debugging enabled and silently retry a couple of times
before complaining about this.
Best regards, Arjen
PS I'm adding Bill Blessing to the list of CC's, since he seems to
have a similar unit.
--
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] NUT SuSE Linux 11.0 USB ULTRA ULT33046 ups
Citeren Bill Blessing billy1...@gmail.com: Sorry for the delay. Too much partying on New Year's Eve I suppose. Anyway, I've attached an usbsnoop log file that I ran for a small amount of time. If it needs to be longer let me know. Also, I've pasted the results below of the first bit of it. Let me know what you think. Thanks! This looks a lot like the protocol used by the (serial) powercom driver. The VID:PID combination is the same as the Advice Partner PRPC650, which seems to use the same Cypress USB to Serial Driver (cypress_m8) core. See my previous message about this. I'm not an usbserial expert, so you'd better ask the developers of this kernel module how you can make this detect this USB to serial device. Once you have the /dev/ttyUSB0 device, the existing powercom driver should be able to support your UPS with minimal effort. 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] online yunto q700
Citeren Dario \subbia\ Cavallaro sub...@gmail.com: Is the patch included into official nut release? If yes, which version. Otherwise, is there a feature request for the inclusion of this patch? This is the version installed by ubuntu 8.10: r...@mio:~# dpkg -l|grep nut|grep core ii nut 2.2.2-6ubuntu1 The core system of the nut - Network UPS Tools This one should support this device out of the box. But chances are, the Ubuntu packaging is broken and that the udev support isn't installed properly. Run the driver with debugging enabled to see where things goes wrong: megatec_usb -D -a yunto You'll have to stop the driver with ctrl-C, since it will stay in the foreground. 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] online yunto q700
Citeren Dario \subbia\ Cavallaro sub...@gmail.com: Ok, strange result.. the ups is still attached, the id is the same, but it is ignored by the driver. My mistake. I failed to notice the different productid of this device. You should be able to connect to it by adding a couple of variables to the ups.conf entry: [yunto] driver = megatec_usb port = auto desc = yunto q700 subdriver = agiler-old vendorid = 06da productid = 0002 Sorry about the confusion. We won't be able to support this out of the box for now, since we already have another driver that is using the same VID:PID combination. Adding an another (incompatible) driver will break existing installations that rely on a HAL addon that might be in use. It could be done, by trying out both at the time of connecting, but this will require merging the megatec_usb and bcmxcp_usb drivers somehow. At runtime, this could then select the appropriate protocol handler. 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] NUT, Ubuntu and Serial Ports
Citeren Huge h...@huge.org.uk: I am about to retire my Sun Solaris workstation and replace it with a Intel box (A Dell Inspiron 530) running Ubuntu. My UPS (an APC SmartUPS2200) only has a serial port for communicating with its controlling host. The Sun has a serial port, but the Dell doesn't. So ... what kind of serial port should I get? I don't really want to waste a precious PCI slot on a serial card (unless I can get a combo card with, say, an RS232 port and a firewire port). OTOH, I know nada about the USB to RS232 adaptors now widely available. Prolific PL-2303 based USB to RS-232 adapters will probably cause the least hassle. I have a couple of them from various brands and they all work flawlessly. I've seen mixed results with Cypress Semiconductor (another popular one) which seem to be working fine for some people and not at all for others. YMMV. 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] online yunto q700
Citeren Dario \subbia\ Cavallaro sub...@gmail.com: Just an idea (obviously OT from the topic) but why not writing a dedicated driver and let users configure it in ups.conf? It seems to me the most obvious solution without breaking existing installations. The drivers that incorporate USB to serial conversion are mostly an interim solution (at best). Most of these problems would cease to exist if support for the USB to serial converters was build into the kernel. Adding that, probably requires some vendor support from the supplier of the USB to serial converters. 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] Strange ups.load and battery.temperature with an APC Back-UPS RS 800 (NUT v2.2.2)
Citeren Jean Delvare kh...@linux-fr.org: These problems might be related. In order to find out what is wrong, run the 'usbhid-ups' driver with debugging enabled (-, not higher) to see what is going on. For reference, I have an APC Back-UPS RS 800 here and it says (with NUT 2.2.2): battery.temperature: 29.2 (...) ups.load: 33.0 The load value is correct. The temperature is fake (it never changes.) Same firmware version as in the original report (9.o4 .I). Interesting. Still I would like to see the debug output. There are many places where this problem can originate. UPS, computer, driver, server, client and all the interfaces in between. Having the debug output from the driver allows us to narrow this down if this is a problem between UPS and driver (and therefor maybe existent only in this particular setup) or something that is introduced between driver and client (not related to the UPS). 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] APC Ups with auto port fails to shut down
Citeren Charles Lepple clep...@gmail.com: I have set the driver name to newhidups and the port to auto. What version of NUT are you using? The newhidups driver was renamed in nut-2.2.0 so it must be nut-2.0.5 (or older). Which means it is well over two years old at least. You should upgrade to a more recent version before trying anything else. We no longer support the version you're using. 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] Success: Digitus DN-170020
Citeren Benjamin Hase benjamin.h...@googlemail.com: just want to report a successful installation of the Digitus DN-170020 UPS. Thanks for reporting this, we appreciate feedback like this to keep our list of supported devices current. Works mostly without problems with the megatec driver and the included cable, a few issues arose: - the toggle beeper command seems not to work for this UPS. This is a known problem that is mentioned in the manual page 'man 8 megatec'. - to shutdown and cut the power line, a delay has to be inserted for the driver; without the UPS just beeps but does not switch off. I'm not quite sure I understand what you mean here. Where did you add this delay? - the test commands do not work for this UPS. Known problem too. Many vendors use this protocol (or something that is similar enough to be understood by the megatec driver) without fully implementing it. I think, these problems are based on firmware flaws. Yes. What works so far: - reporting of power failure - automated shutdown (tested with upsmon -c fsd) - automatic restart (after the two minutes set in config file, not tested with real power cut) If you would have added the output of 'upsc' too, you would be the winner of our grand prize today. :-) What is unknown: - accuracy of sensor values (temperature, voltage, frequency and so on) 'A UPS is not a measurement instrument' (tm) As long as the UPS reports its critical state early enough, I don't bother about the sensor values ;-) Indeed. If in need, I can post my config files, too. The config files are not needed, but it would be nice to see: - the output of 'upsc' - what you did to make the UPS shutdown If you can send this, I'll add it to the list of supported devices. 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] SOLA-330 2 Questions !!!
Citeren Scott Evans sc...@vk7hse.hobby-site.org: I was recently given a SOLA-330 UPS However, it didn't come with the comms cable so I'm having some trouble trying to find a pin-out for this UPS and secondly exactly what driver to use with NUT ?? I've got the users manual for a SOLA-325 (from website) and this has a pin-out for this model but clearly it's not the same for the 330 as I have tried to make a simple cable using... ( RX TX lines and ground only, this cable I believe is my main problem!) UPS - PC 1-2 2-3 4-5 You'll probably need some other lines to, to make sure cable power is provided. In many cases, this is mandatory for reliable communication. And with this I then attempted to fire up NUT using the suggested driver of megatec however I get the error message of Communications with UPS u...@localhost lost so clearly the driver is finding what it wants to see! and then it informs that... UPS u...@localhost is unavailable This could be due to the above problem. Try if running the driver in debug mode like megatec -DDD -a ups reveals some additional information. UPSD.CONF ACL all 0.0.0.0/0 ACL localhost 127.0.0.1/32 ACL firewall 192.168.0.1/32 This will only allow the external interface of the local machine. I don't think this is what you intended, since in that case you had better used 'localhost' instead. If you want other machines to connect to this server, you'll have to relax your netmask. ACCEPT localhost ACCEPT firewall REJECT all 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] Problems with Unitek Alpha 1000 Ps
Citeren Jordi Moreno jmor...@cim.es: I'm attaching usbsnoop.log.tgz. I've tried to keep the log as little as possible, only logging Winpower agent's start. I hope it will help... It does. This looks like a Q1/megatec protocol UPS, unlike what I expected based on earlier megatec logs: out: 46 0d 4d 6f f1 cf 11 88 F \r in : 23 32 33 30 2e 30 20 30 30 30 20 30 31 32 2e 30 20 35 30 2e 30 0d 00 00 # 2 3 0 . 0 sp 0 0 0 sp 0 1 2 . 0 sp 5 0 . 0 \r out: 51 31 0d 6f f1 cf 11 88 Q 1 \r in : 28 32 31 36 2e 30 20 32 31 38 2e 30 20 32 31 31 2e 30 20 30 30 30 20 34 ( 2 1 6 . 0 sp 2 1 8 . 0 sp 2 1 1 . 0 sp 0 0 0 sp 4 39 2e 39 20 31 33 2e 36 20 32 34 2e 30 20 30 30 30 30 31 30 30 30 0d 00 9 . 9 sp 1 3 . 6 sp 2 4 . 0 sp 0 0 0 0 1 0 0 0 \r So based on this log, I would have expected that the UPS would be supported by the megatec_usb driver out of the box. Going back to your first post, it looks like the megatec_usb driver only read the last 8 bytes of the answer to the Q1\r command. The reason could be the somewhat dodgy way of reading the reply from the interrupt report in this driver. It really doesn't handle unexpected lengths correctly. Could you try the latest bleeding edge version from the SVN trunk instead? There is a new driver (blazer_usb) that deals with this better. 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] Problems with Unitek Alpha 1000 Ps
Citeren Jordi Moreno jmor...@cim.es: Couldn't test SVN version. After downloading, autoreconf --install gives me the following output: # autoreconf --install aclocal: macro `NUT_OS_FUNCTIONS' required but not defined aclocal: configure.in: 65: macro `AM_PROG_CC_C_O' not found in library autoreconf: aclocal failed with exit status: 1 You probably don't have all the autoconf tools needed installed. I don't know how to fix this though. Maybe I'm missing something... However, I've tried last testing version (2.4.0-pre2), because it seems to include the same version of blazer_usb.c, blazer.c and blazer.h (checked with diff). Indeed. That's a good alternative to running the SVN version, although it is a bit more difficult to get to any changes that I may need to commit to this driver based on your input. At first, it seems to detect the UPS properly: # bin/blazer_usb -a unitek -u root -x vendorid=0665 -x productid=5161 Network UPS Tools - Megatec/Q1 protocol USB driver 0.02 (2.4.0-pre2) Supported UPS detected with megatec protocol Vendor information read in 1 tries Good. Note that specifying vendorid and productid is useless without also specifying the subdriver that needs to be used. Since the driver already knows them, it is not needed to list these. But if I try to send a shutdown command: # bin/blazer_usb -a unitek -u root -x vendorid=0665 -x productid=5161 -k Network UPS Tools - Megatec/Q1 protocol USB driver 0.02 (2.4.0-pre2) Initiating UPS shutdown instcmd: command [shutdown.return] failed instcmd: command [shutdown.return] failed instcmd: command [shutdown.return] failed That could be due to an unsupported ondelay and/or offdelay value. Try if different values help here. It could also be that your UPS responds with an unsupported return value. You may wish to run the driver as follows to debug this bin/blazer_usb -DDD -a unitek -x ondelay=3 -x offdelay=60 -k This will make the driver run the shutdown command only with enough debugging info to see what is happening. And giving more debug information: # bin/blazer_usb -a unitek -u root -x vendorid=0665 -x productid=5161 -D Network UPS Tools - Megatec/Q1 protocol USB driver 0.02 (2.4.0-pre2) debug level is '5' ... Checking device (0665/5161) (003/003) - VendorID: 0665 - ProductID: 5161 - Manufacturer: WayTech Development(S) - Product: WayTech USB-RS232 Interface (V1.0) Baud rate 2400bps - Serial Number: unknown - Bus: 003 Trying to match device Device matches Trying megatec protocol... send: Q1 read: (218.0 216.0 187.0 000 49.9 13.6 24.0 1000 send_to_all: SETINFO input.voltage 218.0 send_to_all: SETINFO input.voltage.fault 216.0 send_to_all: SETINFO output.voltage 187.0 send_to_all: SETINFO ups.load 0 send_to_all: SETINFO input.frequency 49.9 send_to_all: SETINFO battery.voltage 13.60 send_to_all: SETINFO ups.temperature 24.0 send_to_all: SETINFO beeper.status disabled send_to_all: SETINFO ups.type offline / line interactive send_to_all: SETINFO ups.status OL Status read in 1 tries Looks good. Supported UPS detected with megatec protocol send: F read: #230.0 000 012.0 50.0 send_to_all: SETINFO input.voltage.nominal 230 send_to_all: SETINFO input.current.nominal 0.0 send_to_all: SETINFO battery.packs 1 send_to_all: SETINFO battery.voltage.nominal 12.0 send_to_all: SETINFO input.frequency.nominal 50 Ratings read in 1 tries Same here. send: I read: #UNITEK POWERSCU8UPEG V8.0 send_to_all: SETINFO ups.mfg UNITEK send_to_all: SETINFO ups.model POWER send_to_all: SETINFO ups.firmware SCU8UPEG Vendor information read in 1 tries I was already slightly worried about this. Your UPS has spaces in the manufacturer name, which is unexpected. It looks like I need to change this, to use fixed length values. [...] And it seems to stand forever sending those Q1 commands... That's correct, that's what you get in debugging mode. Well, it seems we've advanced somehow... at least I can read some values from the UPS now. But I really need the shutdown command to work... By the way, trying to execute upsd: # /usr/local/ups/sbin/upsd Network UPS Tools upsd 2.4.0-pre2 listening on 127.0.0.1 port 3493 Can't connect to UPS [unitek] (blazer_usb-unitek): No such file or directory You need to use 'upsdrvctl' to start the driver. 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] Problems with Unitek Alpha 1000 Ps
Citeren Jordi Moreno jmor...@cim.es: chopito:/usr/local/ups# bin/blazer_usb -a unitek -u root -x vendorid=0665 -k -D Try bin/blazer_usb -a unitek -u root -x offdelay=60 -k -DDD instead. Your UPS may not understand an offdelay smaller than 60 seconds. 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] Logging using upslog problem
Citeren Anna Hopkins molto.li...@gmail.com: I upgraded from V2.2 to V2.4. I use the upslog command to log the values of my belkin ups (belkinunv via serial port). It would occasionally start to record garbage, but it would always go back to normal in V2.2 if I restarted. In V2.4 it would not record the values, and the process would fail after the next interval had passed. I had set if for 300 seconds. I walked through the upslog options (I use all the options) and I found out that by eliminating the -i interval option it works perfect. I also tried changing the -i version to 150 seconds, but it doesn't work. Is there something I'm missing. Right now, I am letting the logger work using the default, but every 30 seconds seems like too much information. Is there something I am missing? No, this is due to new behaviour of the 'upsd' server. It will disconnect clients after not hearing from them for more than 60 seconds in order to prevent that clients that don't cleanup after themselves from keeping connections open. What you're seeing, is due to the fact that upslog will open a connection to the server only once. If it fails, it will reconnect, but not read the data immediately afterwards. So the next time when it visits the server, it will again have timed out and the process starts all over again and it will never read anything useful anymore. The solution to this would be to connect, read the data and disconnect. Clients should not keep connections open if they don't intend to use them within the next 60 seconds. 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] Adding a 'refresh' value to the upsstats web page
Citeren Jim Neeland n...@neeland.net: I'd like to have the UPS status web page automatically refreshed. I've found a reference to using @REFRESH@ in the upsstats.html page, but as far as I can tell in looking at the code, somewhere I need to provide a value to the refreshdelay variable, and I see no way to do that other than changing the source code. I'm using nut 2.2. This value is passed to upsstats.cgi through the 'refresh' value in the URL: http://www.example.org/upsstats.cgi?refresh=5 You'd also need to add @REFRESH@ in 'upsstats.html' page, since that's not in the default one shipped so far (see 'man 5 upsstats.html' on how to do that). 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] ordered shutdown
Citeren Lars Täuber taeu...@bbaw.de: [...] The values of X and Y depend on how long the clients need for finishing their business with the SQL servers (X) and how long the SQL servers needs for doing their thing on the NFS servers (Y). This seems dangerous to me. Just think of the following situation: The ups has a normally 60 minutes of time left before shutdown after power loss. In this case I would use 40 mins for X and 5 mins for Y. The above values would be an extremely bad idea and this is also not how NUT works. See the FAQ. Lets assume a power outage of 38 min has happend before it power gets back. The servers still run and the shutdown sequences get canceled. The batteries now can bridge only 22 mins on a second outage. This would lead to an unexpected shutoff for those servers. The battery charge status has to get into account additionally to manage such situations. What you describe is not how NUT works. Until the UPS signals that the battery is low, it is business as usual (see the FAQ for the reasons behind this). Once the UPS signals battery low, all timers are started at the same time and there is no way to stop the following sequence of events. The systems *will* go down. If the power returns during the shutdown sequence, the shutdown sequence will be completed and NUT will power-cycle the UPS to make sure the connected systems are restarted. This means the value of X should only allow for enough time for your clients to disconnect (say about 5 minutes) and Y should only allow for enough time for your SQL servers to write their data to the NFS (maybe another 5 minutes). Typically, you should then allow for about 10 minutes runtime remaining before signaling low battery and starting the shutdown. The reason is that once the clients start shutting down, your runtime remaining will rapidly increase due to the lower load. If you feel uncomfortable with that, give it 15 minutes. There is one important thing here and that is that you need to be able to configure when the UPS signals low battery (and preferably also be able to prevent it from restarting below a certain threshold). This should allow for enough runtime remaining for an orderly shutdown of all systems. If you can also guarantee that the UPS will not power up again if the battery has not been recharged to that level, there is absolutely no risk and you will even ride through successive power failures without being harmed. Most (if not all) bigger UPSes will allow you to set what NUT calls 'battery.charge.low' and 'battery.charge.restart'. Some will even allow you to set 'battery.runtime.low' directly, which may make your life even easier since you no longer have to worry if the load on your UPS increases over time (it will automatically start the shutdown sequence sooner). 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] ordered shutdown
Citeren Charles Lepple clep...@gmail.com: Our network system is quite complex and we need shutdown sequence levels. The servers depend on each other because of NFS and SQL connections and the like. There is a bit of sequencing in the master/slave protocol, but I have not had the time to set something up to try your particular situation. Basically, this needs to be dealt with in the client application. Since we don't provide Windows clients (which Lars apparently is using), I have no idea if this is possible with those. Using the 'upsmon' client (but this requires some sort of *NIX system) this is a trivial however, by staging the FINALDELAY time we have in 'upsmon.conf'. Assuming there are clients connected to the SQL servers which in turn require NFS service you would use something like the following FINALDELAY 0 (for the clients) FINALDELAY X (for the SQL servers) FINALDELAY X+Y (for the NFS servers) The values of X and Y depend on how long the clients need for finishing their business with the SQL servers (X) and how long the SQL servers needs for doing their thing on the NFS servers (Y). You'll want a sufficient 'ups.delay.shutdown' period to make sure that all systems have not only started their shutdown sequences, but have also finished them before the power is actually cut. The use of FINALDELAY in the above only sequences the start of the shutdown, so it doesn't know when the systems are actually switched off. This is by design, since you don't want to stall shutting down if one system is unresponsive or takes longer to shutdown than expected (which would put all remaining systems at risk for a hard shutdown). 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] ordered shutdown
Citeren Lars Täuber taeu...@bbaw.de: it seems I understood how NUT works now. But then it is not the solution for us. The reason simply is we have one big ups for so many servers. And it's a bad idea to have one point in time to shutdown all servers. So one »battery low« signal for all servers is not what we need. In that case, I probably don't understand what you're trying to do. There are some servers that should work as long as possible and shut down shortly (2 minutes) before the ups shuts off. But these server also should try to shut down and that's why they need the connection to the ups too. So you want the servers to keep running as long as possible and the clients should go down after a power outage of (say) five minutes? That's possible too. Is it possible with NUT to tell upsd to initiate a shutdown by the means of upssched? As long as I understood upssched doesn't run as root. So it can't be used to initiate a shutdown directly. Sure. But if you can describe more clearly what you're trying to do, we might come up with other alternatives as well, as I don't think this is what you want to do. 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] ordered shutdown
Citeren Marco Chiappero ma...@absence.it: I think I know what he meant, because my needs are similar. I already explained them some time ago, when I discovered that NUT comes with no features at all about programmable outlets (right now I still have no shutdown sequence settled yet). When you have one ups and many computers with different needs the low battery signal starts having no use (well, it can be useful but just for the last computers you want to shut down). If you want to conserve power on your UPS, you should simply send a client a command to shutdown. While it is shutting down, it makes no point to cut the power and after that, the remaining power it draws is so small, that cutting power is moot. You *will* need programmable outlets if you need to restart/reboot part of loads attached to a UPS. That comes in handy if you want to shutdown some servers earlier than others, to prevent that your only option is to power cycle *all* loads to make them start again if the power returns before the battery is empty. We're currently working on implementing this and already have made some progress in that direction (see the latest nut-2.4.0 release where a repeater mode was added) so you can have 'virtual' UPS devices. Basically what is lacking right now, is tying these virtual devices to UPS outlets and a way to configure the shutdown/restart levels for these outlets. We have some ideas on how to do that, but it is currently lacking development time to implement this. [...] In my opinion that's a limitation and, again in my humble opinion, poor design. It sounds like refuelling a car on a $TIME schedule rather than an avaiability basis: I use to refuel when the *real* remaining fuel is below a certain value/charge, do you use to refuel on a *supposed* fuel consumption over $TIME? This is actually how battery charge calculation works on a UPS, strange as it may seem. Most (if not all) batteries don't come with fuel gauges like your car, so all but the cheapest UPS systems will constantly keep track on how much charge is going in an out of the battery to calculate the charge in the battery. Having said that, you should *always* take into account that the battery capacity may be less than expected (calculated) due to aging batteries, so you can never fully rely on the reported battery.charge and battery.runtime. If you search the archives, you'll find plenty of examples where people found this out the hard way. This is one reason why one should periodically run battery tests to find hidden battery problems that only surface under load. 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] ordered shutdown
Citeren Marco Chiappero ma...@absence.it: If you want to conserve power on your UPS, you should simply send a client a command to shutdown. How can I do that? How can I shutdown different systems at different battery charge levels (or expected runtime)? I thought the only option aviable was using upssched. Well, that is the whole point now, at the moment there isn't. Switching off systems at various battery.charge/runtime levels is only useful, if you can also switch them on again. This is where the programmable outlets come into play. We first need to deal with that. Hopefully we will have something available by summer, but don't hold your breath. The number of active developers is quite limited at the moment and personally I feel that there are more important things to work on at the moment. [...] I'm sorry, I didn't state explicitly I was talking about upssched. I prefer to choose when to shutdown the computers looking at the battery charge or the remaining runtime rather than after X time. This is something you will rarely find on no-name consumer grade UPS, but as far as I know the more well known brands (MGE, APC, Tripplite) support this out of the box for their systems. 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] ordered shutdown
Citeren Julian Stacey j...@berklix.org: As batteries age, they might (or not) retain most of their Amp Hour capacity, but as their internal resistance increases, can't deliver same peak current load as a newer lower internal resistance battery. The internal resistance usually increases because of loss of active surface area in the cells (shedding lead from the plates and sulfatation) and (for VLRA cells) by drying out. All these effects not only cause higher resistance, but also lower the Amp hour rating. An on line battery test does not tell much, just a binary Worked/ Failed, (unless it tells more by comms port to NUT?) I would guess few (if any ?) UPS might have current measuring, for prediction ? None of the 5 or 6 UPS I have serviced have individual voltage sensors to individual batteries, so UPS Nut can only measure the whole stack, as some UPS use eg 4 x 12V 17AH @ 60 Euros, replacing all 4 when only some need it, is expensive. The only reliable way to determine this, is by running a (periodic) deep discharge test, either through a build in command or by pulling the plug. There is no need to remove batteries out to do this. 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] ordered shutdown
Citeren Gabor Gombas gomb...@sztaki.hu: Most server-grade boxes have IPMI support and that's _very_ convenient not just for turning the machine on/off. Also, we have good experiences with simple Wake-on-LAN for cheap boxes: it's not 100% reliable, but it is good enough to be useful (and if a machine does not have IPMI support then it cannot be that important ;-) With whatever strategy you use, you need to be able to send some kind of command (power on, WOL magic, whatever) at the right time. Shutting down is 'easy' when there is one point in time where you can decide to shutdown whatever is connected (what we have now) possibly with some kind of sequencing and then power cycle the UPS. What people are asking now, is to have multiple decision moments and for each one you must guarantee that you're able to return to the normal state with as little impact on other systems. This is something completely different. IMHO nut is currently quite good at the low-level HW support but there is a real need to provide support for centralized, high-level power on/off plans. And centralized is a very important keyword here; having to modify upssched scripts on dozens of machines when the plan changes is a real PITA. In that case, put these scripts on a network drive. They don't have to live in /etc/ups (or whatever is compiled in). In networked environments with lots of similar systems it is much more convenient to do this on a NFS share. 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] ordered shutdown
Citeren Marco Chiappero ma...@absence.it: NUT is handy if you want to shut down one or many systems in the same moment but not in such case (upssched, is not even part of the core and does not fully fits these needs). No, at the moment NUT only support if the decision to shutdown is made at the same time. This doesn't mean the systems have to be shutdown at the same time. Note there is a destinctive difference between these two. [...] This is something you will rarely find on no-name consumer grade UPS, but as far as I know the more well known brands (MGE, APC, Tripplite) support this out of the box for their systems. Sorry, what you mean? Not every UPS can shutdown whenever you want? Or not every UPS provide battery charge reading? Not every UPS allows you to change when it considers the battery voltage low and consequently, when you *must* shutdown your systems. Some no-name models will not even allow enough time to shutdown. 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] ordered shutdown
Citeren Marco Chiappero ma...@absence.it: And centralized is a very important keyword here; having to modify upssched scripts on dozens of machines when the plan changes is a real PITA. I agree, and that's the reason why I said there is a need for a director. It takes care about settings and actions, clients should only obey and possibly show UPS informations. It's also a metter of role: the system managing the UPS is the only one that should decide and control who can keep running and for how long, not the server administrator (and maybe you're not even the server owner or admin)! This should also make the powershare feature easier to implement since the computer controlling the UPS knows everything. Please elaborate here, because as far as I know we already have this (the 'upsd' server). What we're intending to do is to add additional 'upsd' servers (per outlet) that are configurable to some extend allow you to set additional shutdown parameters. But these additional servers would all be slaves to the server controlling the UPS, since by the time that one decides the UPS battery is empty, there is nothing to to but to shutdown. 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] ordered shutdown
Citeren Gabor Gombas gomb...@sztaki.hu: The first step would be to have a _central_ way to manage when to shut a specific class of clients down. Having to muck with upssched scripts on every client just does not scale. IMHO the clients should just say hello, I'm of class X when logging into the UPS, and it should be upsd's job to say clients of class X start to shut down NOW, everyone else wait. This would still require configuration on the part of the clients to set the class. But I agree with the fact that this should be managed in a centralized way. I intend to do this by adding 'virtual' UPS devices that clients can connect to in the usual manner. By doing so, the interface to existing client applications (not only the ones we provide) remains intact. So something like big-...@example.com (actual UPS) whatever@example.com (virtual UPS) In this case, clients can connect to either of the above (or more than one), which will look to them as a 'real' UPS. All the power sequencing would be handled on the server, including the decision to shutdown a certain virtual UPS. Doing so effectively means that from the moment this is added, all existing clients can start using this. Being able to turn clients that were logged in to the UPS when their shutdown was ordered back on is the next logical step after the above, but for a start I'd be happy with the shutdown part. Noted. If you're not already subscribed to the nut-upsdev mailinglist, please do so, since usually changes like the above will be announced there first. 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] ordered shutdown
Citeren Marco Chiappero ma...@absence.it: This would be useful too, but I would be happy enough just having different shutdown moments based on timer|charge|runtime as apcupsd and MGE's psp[1] do natively (and as it should be)! It's funny that you mention MGE PSP here, since except for the shutdown timer (reason explained in the FAQ), NUT already provides *all* functionality it has (including shutdown based on charge and runtime). What you may be missing is the fact that this requires setting values on the UPS through the 'upsrw' command to control the level when the UPS will decide the battery is low. What we currently don't have, is multiple decision levels, but this is something that will be dealt with through the use of virtual UPS devices that are accessible through the regular interface. In that case, put these scripts on a network drive. They don't have to live in /etc/ups (or whatever is compiled in). Obviously you can do it, but it's not a much better solution. Having to set up a file server to accomplish what, in my opinion, NUT should do natively it's certainly not a solution. That depends a lot on your configuration. If you already have many more or less identical clients on your system, chances are that this file server will already source the configuration for these systems. I know of quite a couple of large installations where NUT is used where this is the case and this is quite a workable setup. [...] 1) different shutdown criteria We already have that if the UPS supports it. If it doesn't support it, we don't and won't do that. There is far too much crappy UPS hardware around to add this for units that don't support this natively. 2) different shutdown time points This will be added but is currently lacking development time and attention. 3) automatic restart management / automatic programmable outlet power on We won't add #2 without #3. The third is not required for implementing points 1 and 2. Not at all. Without this, unattended shutdowns are just not an option, which is the base of NUT. The first one is absolutely the most important and already present in any UPS tool I've seen. See above. For devices that support this, NUT already has this. If I remember correctly you have a MGE Evolution 650 and I know that this is supported (for a couple of releases already). What is much more important than the issues you raise, is the fact that configuration of NUT is much too complicated at the moment. Many people simply give up because of the overwhelming amount of configuration required to setup simple monitoring of their UPS. 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] ordered shutdown
Citeren Marco Chiappero ma...@absence.it: Please elaborate here, because as far as I know we already have this (the 'upsd' server). Please read the last mail from Gabor, his idea it's really close to mine. To me clients have to be as stupid as possible (requiring almost no configuration) and simply obey to commands issued by the server. This means that clients shutdown configuration has to be done on the machine controlling the UPS(es). This way it is the server (connected to the UPS) that allows someone to use the UPS it owns for the time it considers fine, it is not a client that tells the server how much it wants to stay up (a slave upsmon works this way, right?). If you run the upsmon master on the same box as the upsd server, all upsmon slaves connected to the same UPS will shutdown at the same time as the upsmon master. So effectively, you already have a centralized setup if you configure things properly. There is absolutely no need to run 'upssched' on every client if they should all go down at the same time, just run it on the master and you'll be fine. The only thing that remains is that we need different 'virtual' UPSes that can be shutdown at different battery.(charge|runtime) levels and you have pretty much exactly what Gabor describes. 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] ordered shutdown
Citeren Marco Chiappero ma...@absence.it: It's funny that you mention MGE PSP here, since except for the shutdown timer (reason explained in the FAQ), NUT already provides *all* functionality it has (including shutdown based on charge and runtime). What you may be missing is the fact that this requires setting values on the UPS through the 'upsrw' command to control the level when the UPS will decide the battery is low. As far as I remember in PSP there are two different regulations, battery charge level that triggers system shutdown and battery charge level that set the low battery state. I suppose it uses the first one that occurs. If I'm not wrong. You're wrong. :-) In MGE PSP you can set the equivalent what we call in NUT 'battery.charge.low' and 'battery.charge.restart'. The first will determine the level that triggers the 'battery low' warning (and system shutdown), but the second does something completely different. You don't want to restart your systems if there isn't sufficient battery charge left to cleanly shut them down. Imaging that the power returns, but fails after one or two minutes again (maybe the fuse that was replaced, blew again). In that time, the server will probably have restarted, but the UPS batteries will still be almost empty and there may not be enough time to shutdown cleanly. This is where the 'battery.charge.restart' level comes into play. It will make the UPS not power up the outputs again until the battery has been recharged to a certain level again (which of course should be enough to do a full restart/power down cycle). In that case, no matter how often the mains fails, there will always be enough juice in the battery to shut your systems down cleanly. See also what is written about this at the bottom of 'docs/shutdown.txt'. Generally speaking, the 'battery.charge.restart' level should be *higher* than 'battery.charge.low' (if you understood the problem, you'll know why). 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] early shutdown of VMware VMs
Citeren David Newman dnew...@networktest.com: How to shut down VMWare guest virtual machines earlier than the host machine they run on? (For example, if everything normally shuts down at 5% UPS battery, then the VMs should shut down at 10%.) First question is, why do you want to do that? Because a clean shutdown of the VMs is more important than high uptime for the VMs. If both guest and host machines shut down at the same time, the host might finish its shutdown before the guests have, leading to possible filesystem corruption. I will gladly trade off some downtime of the VMs to ensure clean shutdowns. I would be really surprised if this couldn't be handled by VMWare. Briefly looking at some Googled pages, it seems that the host can signal the guests to shutdown and I assume it should also be possible to check if they have indeed done so. If that's the case, the host should signal the guests that they need to shutdown, wait until the last one has finished and proceed with shutting down itself. Scripting this should be pretty straightforward. [...] I'm not an expert on VMware, but I would expect that you can configure on the host that it shuts down the guests before going down. Thanks -- that's what I'm asking for -- what is it that I configure, and are there sample configs someplace that do this? You should really ask on a VMWare mailinglist how to do this. We can help you shutdown your systems, but not any application (including VMWare) it may be running. Usually, NUT expects system halt scripts to be dealing with this (with or without NUT running). Even for a system that is running 24/7, I would still want that. If they need to be brought down for maintenance, I don't want to have to think about what needs to be stopped, before it is safe to type 'halt -p' on the console. 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] ordered shutdown
Citeren Marco Chiappero ma...@absence.it: You're wrong. :-) I don't think so :-) Yes you are. :-) Yesterday I had a try with my windows laptop. Here you can see how it works: http://i43.tinypic.com/2n20778.png You can configure NUT to shutdown at a certain battery.charge too, with the UPS you're using, that's what I have been telling you a couple of times already. Go read 'man upsrw' and fire it up for your UPS. You'll find that you can freely configure the 'battery.charge.low' on it. You can set the low battery level as a lower bound, so you have a low_battery - full_battery interval where you can freely place a time point, on different basis, which start the shutdown procedure. That's what I'd call freedom of choice, I can choose what event should trigger the shutdown and when (without recurring to external utilities), you just have not to be in low battery yet. It is something important that many software already have. NUT has it too for devices (including yours) that support setting this. Moreover I'd like to choose, in this low_battery - full battery range, when to powerdown different systems, still on different basis. This won't work with MGE PSP either, so the comparison doesn't hold here. However, the solution you wrote about is fine, so let's wait for implementation. Which is for a totally different thing we're talking about. Please don't mix up configuration of battery.charge.low (which is already supported) and multiple shutdown levels for different outputs (which currently isn't supported). The example you're giving here, has nothing to do with ordered shutdowns. Thank you again, but I have read every single piece of documentation aviable, I'm just waiting for the features I need ;-) I beg to differ here... :-( 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] ordered shutdown
Citeren Marco Chiappero ma...@absence.it: Well, right, but PSP it's not intended for network use, while NUT indeed it is. I took it as example for showing the above reason and how easy is to choose from different criteria in a standalone environment: http://i39.tinypic.com/2mpy9s6.png You hit the nail on the head. While it is fairly easy to change shutdown parameters in a standalone application, this is not so easy in a networked environment. In a standalone application, you can rest assured that once the shutdown condition has been reached, the system *will* go down and recovering from that is fairly straightforward too (since this will be dealt with by the UPS itself). No need to deal with transient conditions. In a networked environment with multiple shutdown levels, you'll also have to deal with transient conditions and also with the situation where the power returns between two levels (and how to recover from that) and making this system fail safe too. This is vastly more difficult to handle. If I'm not wrong it should be pretty easy to set up ordered shutdown with different criteria in apcupsd too. Me and some other people reported that actually NUT can't easily cope with similar requests. Is there something more to comment on that? Yes, there is. If extending runtime by shutting down loads is essential to you, chances are that what you really need is a generator. Most of the power outages you'll experience in everyday life will be short lived (in the order of seconds, mainly due to switching operation in the grid), which are corrected automatically. This is something that can dealt with easily with the runtime of basically any UPS in existance. Longer outages are usually mean that something is broken that can't be corrected automatically and/or requiring human intervention/replacement of systems. This means that the outage will be much longer than the runtime of UPS batteries. No matter how much load you're shedding. Even at no load, most UPS systems won't hold up longer than about 45 to 60 minutes. If you've already used up part of the juice, it will be even less. So you're systems *are* going down in that situation. If losing (some) systems is really a big deal to you, having a UPS is only part of the solution. Personally, I feel the option to shutdown part of the loads depending on battery charge or runtime remaining is largely a waste of effort. You'll still have to deal with the situation where the battery state triggers shutdown on all systems at the same time (after recovering from an outage, followed by another outage for instance). [...] So, I'll keep waiting for the features. :-) ...instead of working toward a solution. You see where the root of this problem lies? The active developers don't have this high on their list of features and the people that want this, don't provide any help in adding them. Don't hold your breath waiting. ;-) 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] NUT 2.4.1 crashes on FreeBSD - additional info
Citeren Volker Theile vot...@gmx.de: Ahmmm, just wondering how this could happen and why nobody has realized this bug during the testing phase :-) Testing can only confirm the presence of bugs, not the absence. This error was already present since (at least) January 2005, which probably means that you need to match a fairly specific set of conditions to run into problems here. Apparently, your system did. Because problems with overflows for (void *) elements in function calls are difficult (if at all) possible to spot for compilers, this didn't trigger any alarms. The memset() function is probably not needed here anyway, so clearing the wrong (global) variable didn't lead to problems either. Depending on the size of both 'struct sockaddr_un' and 'struct sigaction' it may or may not lead to overflows. 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] megatec_usb vs Mustek NetGuard / Ippon SmartWinner problem
Citeren Oleg Pshenychnyy oleg.pshenych...@gmail.com: I have Mustek NetGuard 1000 UPS which is equivalent to Ippon SmartWinner 1000. I have tried to run several latest builds of NUT, but run megatec_usb driver still failed with my device. I hope the information below might help. [...] Try the 'blazer_usb' driver instead. Make sure to read 'man 8 blazer', since there are quite a couple of differences in what the driver reports by default and what needs to be configured in 'ups.conf'. 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] megatec_usb vs Mustek NetGuard / Ippon SmartWinner problem
Citeren Arnaud Quette aquette@gmail.com: Alex, be sure to also address blazer_usb since it's the long run approach. It will already work with this UPS. The problem is in the way how the phoenix subdriver in megatec_usb deals with reading data from the UPS. Currently, it reads data until it receives a timeout or the supplied buffer is full. This will work for most devices, but not all. The proper way to do this (implemented in blazer_usb) is to read until either - a read for an eight byte chunk of data times out (which is a timeout error) - the number of requested characters is read - a '\r' character is read (characters following this should be discarded) Also note that currently reading partial data (less data was read than requested) is broken in megatec_usb. Especially Mustek devices often seem to return 7 characters, when we requested 8. 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] megatec_usb vs Mustek NetGuard / Ippon SmartWinner problem
Citeren Alexander I. Gordeev lasa...@lvk.cs.msu.su: Alex, be sure to also address blazer_usb since it's the long run approach. Sure, actually I rechecked blazer_usb after Arjen's mail. Well, it is not really working but it can read Q1 response at least! I didn't notice this previously because the driver then tries to reconnect infinitely and produces lots of output. I'll investigate it. Which UPS and driver are you talking about now? 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] ups.delay.shutdown clarification
Citeren Des Dougan d...@douganconsulting.com: A client of mine has an APC Back-UPS 350 model (USB connected). His office had a power incident yesterday, where there was an interruption of about 30 seconds. During that time, the server shut down. As soon as it went on battery, the daemon initiated a shutdown. In checking it today, I see the ups.delay.shutdown setting is -1. I tried to adjust it, but could not do so. What does the -1 setting mean? It means no shutdown delay value has been configured. I already wrote that we'll need the NUT version and OS to determine what *exactly* is going on. I Googled, but couldn't find anything relevant. Am I correct in assuming it is this setting that caused the immediate shutdown? No, the decision to shut the system down is unrelated to the ups.delay.shutdown value. Most likely (but see the note above), the UPS firmware is broken and it signals low battery right after the power is lost. NUT has no other option than to initiate system shutdown in that case. Note that the Back-UPS 350 is a *very* small entry level UPS that really shouldn't be used for anything other than small desktop systems. Today, the UPS shows a load of 35, via the upsc command, so it doesn't appear it was overloaded. Maybe, maybe not. The only way to conclusively tell why NUT decided to shutdown the system is to run the driver in debug mode. It will probably confirm the above. 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] driver for HP/Compaq T750 ?
Citeren KP Kirchdoerfer kap...@bering-uclibc.de: [...] And the upshid-ups driver ends with: No matching HID UPS found Driver failed to start (exit status=1) Try this driver again, but make sure to add productid = 1f06 to the ups.conf entry for this device. Chances are that it is a re-branded Tripplite unit (we've seen other HP units that are actually this brand). 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] RFC: Use tcp-wrapper for all connections to upsd
Citeren Joerg Pulz joerg.p...@frm2.tum.de: after some experimenting and digging through the code i found no solution how to completely disable access to upsd from specific hosts. On multi-homed servers the LISTEN directive will deal with this, by only listening on interfaces from which clients are allowed to connect. If this isn't fine grained enough, your firewall will keep out unwanted connections much more efficiently than tcp-wrappers (or the now obsolete ACL mechanism) ever will. In previous versions (before r1233) it was possible to allow or deny access to upsd completely by using ACL, ACCEPT and REJECT entries in upsd.conf. As this functionality was removed and tcp-wrappers support was introduced i thought it would be possible to use some rules in hosts.allow to get the same functionality as before. Unfortunately, thats not the case. This is by design. Only authenticated commands like SET or INSTCMD are protected by tcp-wrappers, all other commands like GET or LIST can be used from everywhere by everyone which is IMO a regression. For me, the right solution would be to protect all incoming connections by tcp-wrappers. Using tcp-wrappers for source address access control alone is a *huge* waste of effort, therefor NUT no longer supports this. What do others think about this? The tcp-wrappers support in NUT is only meant to deal with the case where you want to allow access for certain users from a specific set of machines (for instance, administrative access). This means we require the username and password, hence this only works for commands that require to be logged into the server. The previous ACL mechanism was too inefficient (in terms of resources) to be really useful in countering attacks on the server. By the time the decision to allow or deny a client access was made, most of the effort that was needed to process the incoming connection would already have been spent, so there really wasn't that much to gain anymore (other than restrict clients to see what is going on on the server). This is the reason we dropped the ACL mechanism. 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] Nut with megatec_usb
Citeren Gabriel Hahmann gabriel.hahm...@gmail.com: [...] My device is connected in the bus 001, device 004, and when i do a lsusb -s 001:004 -vvv the result is as follows: Bus 001 Device 004: ID 04b4:5500 Cypress Semiconductor Corp. HID-COM RS232 Adapter Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 1.00 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 8 idVendor 0x04b4 Cypress Semiconductor Corp. idProduct 0x5500 HID-COM RS232 Adapter bcdDevice0.00 iManufacturer 1 Cypress Semiconductor iProduct2 USB to Serial iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 41 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 4 Sample HID bmAttributes 0x80 (Bus Powered) MaxPower 100mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 3 Human Interface Device bInterfaceSubClass 0 No Subclass bInterfaceProtocol 0 None iInterface 0 HID Device Descriptor: bLength 9 bDescriptorType33 bcdHID 1.00 bCountryCode0 Not supported bNumDescriptors 1 bDescriptorType34 Report wDescriptorLength 37 Report Descriptors: ** UNAVAILABLE ** Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes3 Transfer TypeInterrupt Synch Type None Usage Type Data wMaxPacketSize 0x0008 1x 8 bytes bInterval 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x02 EP 2 OUT bmAttributes3 Transfer TypeInterrupt Synch Type None Usage Type Data wMaxPacketSize 0x0008 1x 8 bytes bInterval 1 Device Status: 0x (Bus Powered) Anybody knows how to handle this? This device should be recognized by the kernel as a generic USB to serial converter. Usually this means that it will create a /dev/ttyUSBx port for you when you connect it. You can use the megatec driver to connect to this port. Best regards, Arjen PS Don't cross-post to the development mailing list if you don't get an answer immediately. This list is mostly run by volunteers, so give us a little time to answer. -- 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] Nut with megatec_usb
Citeren Gabriel Hahmann gabriel.hahm...@gmail.com: I tried your sugestion, changing the protocol to megatec and putting the port with /dev/ttyUSB0. This didn't work, the output is as follows: r...@comserver:/lib/nut# ./megatec -a sms -DD Network UPS Tools 2.2.1- - Megatec protocol driver 1.5.13 [megatec] Carlos Rodrigues (c) 2003-2007 debug level is '6' Starting UPS detection process... Asking for UPS status [Q1]... Q1 = FAILED [timeout] Asking for UPS status [Q1]... Q1 = FAILED [timeout] Asking for UPS status [Q1]... Q1 = FAILED [timeout] Asking for UPS status [Q1]... Q1 = FAILED [timeout] Asking for UPS status [Q1]... Q1 = FAILED [timeout] 5 out of 5 detection attempts failed (minimum failures: 2). Megatec protocol UPS not detected. Assuming that the usbserial port is working correctly (there have been issues with m8_cypress in some kernels in the past), it doesn't look like this device is speaking Megatec/Q1 protocol. If you upgrade NUT, you might also try out the blazer_ser driver, which also speaks some variations. But it might very well be something completely different. I think that maybe, this version doesn't use the megatec protocol, maybe some variation. Could you or somebody help me to find wich protocol this nobreak uses? I have another server running the windows version of the manuftaturer software, maybe I could sniff or find something. The old version of this manufturer with serial interface uses megatec. Sniffing the output on a Windows box while monitoring the UPS might indeed help us finding out which protocol it uses. If you need instructions on how to do that (for either USB or RS-232 connections), search the archives. 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] Question about Tripplite SU10KRT3U
Citeren Dave Gibson dave.gib...@coloradovnet.com: Hello list! I can't seem to get this running via RS232 monitoring; I've been told that NUT won't support serial connections, and find this hard to verify. Does anyone else have this running on the SU10KRT3U via RS232? If so, what driver did you use? I'm getting no satisfaction from the tripplite driver; upon upsdrvctl start, I get Failed to find UPS - giving up... You may have better luck with the 'tripplitesu' driver for Tripp Lite SmartOnline (SU*) models. 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] Master privileges unavailable on UPS after upgrade to Debian Lenny
Citeren David Smith li...@nobodynet.net: On issuing a /etc/init.d/nut start I get the following in my syslog: Mar 7 00:27:19 copstick3 upsd[26316]: Connection from 127.0.1.1 Mar 7 00:27:19 copstick3 upsd[26316]: Client monu...@127.0.1.1 logged into UPS [copstick_ups] Mar 7 00:27:19 copstick3 upsmon[26319]: Master privileges unavailable on UPS [copstick_...@copstick3] Mar 7 00:27:19 copstick3 upsmon[26319]: Response: [ERR ACCESS-DENIED] [...] upsd.conf # ACL all 0.0.0.0/0 ACL localhost 127.0.0.1/32 ACL localhost2 127.0.1.1/32 ACL nobodynet 10.9.2.0/24 [...] upsd.users ## [admin] password = blarblarblarblar allowfrom = localhost actions = SET instcmds = ALL [monuser] password = blarblar allowfrom = localhost actions = SET instcmds = ALL upsmon master Of course this fails. You're connecting from localhost2 [127.0.1.1] but master privileges can only be set from localhost [127.0.0.1]. 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] Master privileges unavailable on UPS after upgrade to Debian Lenny
Citeren Arnaud Quette aquette@gmail.com: [...] upsd.conf # ACL all 0.0.0.0/0 ACL localhost 127.0.0.1/32 ACL localhost2 127.0.1.1/32 ACL nobodynet 10.9.2.0/24 #ACCEPT http://10.9.2.0/24%0A#ACCEPT all ACCEPT localhost ACCEPT nobodynet ACCEPT localhost2 REJECT all try putting all ACCEPT on the same line, ie: ACCEPT localhost nobodynet localhost2 and restart nut. That might help if NUT woul -- 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] Master privileges unavailable on UPS after upgrade to Debian Lenny
Citeren Arnaud Quette aquette@gmail.com: upsd.conf # ACL all 0.0.0.0/0 ACL localhost 127.0.0.1/32 ACL localhost2 127.0.1.1/32 ACL nobodynet 10.9.2.0/24 #ACCEPT http://10.9.2.0/24%0A#ACCEPT all ACCEPT localhost ACCEPT nobodynet ACCEPT localhost2 REJECT all try putting all ACCEPT on the same line, ie: ACCEPT localhost nobodynet localhost2 and restart nut. That might help if NUT would use the ACCEPT mechanism in the allowfrom processing (which is not the case). To help people out that find this thread through a search tool, I'll explain it once more. In NUT versions earlier than 2.4.0 (where we dropped the ACL mechanism), ACCEPT/REJECT (in upsd.conf) will determine if a connection is allowed in the first place. In order to set master privileges on a UPS, you first need a connection (so there must be a matching ACCEPT before a possible REJECT) but after that you only need to match the 'allowfrom' (in upsd.users) for the user that made the connection. The allowfrom processing only uses the ACL line from upsd.conf, not ACCEPT/REJECT lines. 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] NUT and Ablerex MARS 3000RT
Citeren Snoopy Great great.sno...@gmail.com: I own some Ablerex MARS 3000 (MS3000RT) UPS. Following the thread here : http://osdir.com/ml/monitoring.nut.user/2006-04/msg00091.html I would have the following issues : 1. The battery charge displayed seems wrong : It always shows 100.0 - even when the battery is disconnected for replacement. The battery charge is calculated from the battery voltage reported by the UPS. If this voltage is still present with batteries disconnected, there is nothing we can do about this. 2. Battery voltage 2.29 is also static ...and wrong. The initial assumption of being the voltage per unit seems wrong : the ups uses 8 x 12V batteries. 8*12 = 96V , same as battery.voltage.nominal: which is correct. Again, the battery voltage shown is reported by the UPS. We can't do anything about that if it is static, complain to the vendor instead. Newer versions of NUT will allow you to specify a multiplication value for the battery voltage, so that it will match the total string voltage. This won't help though, if the reported value is static. The initial poster seems to have more credible results at least regarding the battery.charge: variable, however in my case the value is wrong. [...] Any ideea about the cause of the anomalies ? This is a limitation of your UPS. We can't do anything about that. 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] NUT and Ablerex MARS 3000RT
Citeren Snoopy Great great.sno...@gmail.com: Well, the value should not be static, could it be a data parsing error ? No. 1. Manuel has the same ups model, and the charge level showed by nut is not constant. However he seems to be running the initial version from svn. Maybe he read the man page for this driver (or was advised by someone on this list) to setup the 'battvolts' parameter for this UPS. If you didn't configure that, chances are that it will always report 100% charge, since it might fail to determine the battery low and high levels. The UPS doesn't report these and the driver may fail to correctly guess them. See the man page where this is explained. 2. I have 2 identical UPS, I think it's quite improbable that both are defective and send a constant value for both charge level and voltage. The UPS doesn't report the charge level, the Megatec/Q1 protocol doesn't have support for that (yet). It can only report battery voltage at the moment. From that, a charge is estimated. Since this only uses the reported battery voltage, this is notoriously unreliable. 3. The original ups software seems to show variable values for those parameters, but this point I'll have to test a little later (the ups is in production, and it's a little harder to make experiments changing the software and/or disconnecting the main power supply to force ups in OB mode). Is there any chance something else changed between Manuel's version and mine that could explain the misreading ? NUT version? It might also help to upgrade to the latest NUT version and try out the 'blazer_ser' driver. Make sure to read the man page for it, since in some cases it needs some help in setting the right parameters for your UPS. If you feed it the right parameters, it will also do a much better job in guesstimating charge left while running on battery. And looking at the data you provided, it will at least do a better job in determining the number of cells in the battery. 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] Weird Load and Battery Temp Readings
Citeren Bob Blackwell rc.blackw...@yahoo.ca: [...] The systems message.log contains several lines with; Mar 13 19:16:20 DNS323_NAS user.warn kernel: usb 1-1.2: usbfs: process 26398 (usbhid-ups) did not claim interface 0 before use This usually means that more than one driver is active for the same USB device and/or hotplug/udev isn´t setup properly. It could occasionally happen if the connection is lost as well. Issuing a usbhid-ups -DD -a APC_UPS reveals; [...] This debug level is too low to provide enough input. For this problem, you'll need to run it with debug level 5 before it will show what is going on. Please note the following from 'man 8 nutupsdrv': The level of debugging needed depends both on the driver and the problem you're trying to diagnose. Therefore, first explain the problem you have with a driver to a developer/maintainer, before sending them debugging output. More often than not, if you just pick a level, the output may be either too limited or too verbose to be of any use. 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] Nut-upsuser Digest, Vol 45, Issue 13
Citeren Bob Blackwell rc.blackw...@yahoo.ca: From what I can tell three's only one active driver. PS shows; PID USER COMMAND 2045 root /ffp/bin/usbhid-ups -a APC_UPS 2047 root /ffp/sbin/upsd 2049 root /ffp/sbin/upsmon -u monuser 2050 nutmon /ffp/sbin/upsmon -u monuser Could it be that you're running virtualization software and that you're running NUT on one of the slaves? Running usbhid-ups -u root -D -a APC_UPSdebug.log 21 never stops without a ^C. The log shows many disconnect and re-connect attempts. Usually this either means that your USB system isn't setup properly (or you're in a really 'noisy' environment) or that some other process is also attempting to claim the same USB device. This will lead to an endless mess of reconnection attempts for both drivers. USB doesn't really handle this well if you don't use the kernel (HAL) to startup drivers, but instead talk to them directly like we do. We do have HAL addons that would not suffer from this, but these usually are only worth using if you have a graphical desktop. I'm rather green at Linux thus it'll likely take me a couple of days to determine if there's a hotplug/udev issue. Until then I'll refrain from posting debug's output. It looks like this might be caused by an (unexpected) use of signed chars on your system. The HID parser really doesn't cope with that properly in nut-2.4.1 and before. I have attempted to work around that in the latest version in the SVN trunk. I could be that the problem with the strange readings, is that the logic used to calculate the exponent is off by a factor of 10^256 due to problems with the interpretation of (signed char) values as (unsigned char) on your system. If you post debug output, make sure to include the report descriptor, which would be the most valueable part, together with the initial dump of the variables. 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] Driver for UPS Eaton 9130
Citeren Attila Csontos attila.cson...@r-sys.sk: Hi Kjell and Arnaud, I was trying Kjell's command (/path/to/bcmxcp -DD -a pw9130 -u root) and I have got this output: [...] After that driver finished with Segmentation Fault (core dumped). No core file in current directory. If you care to attempt to debug what is going in, it might help to run the above command through 'valgrind'. This will allow examining what causes the segmentation fault. This could be bcmxcp driver specific or (worse) be caused by an error in the main driver core functions. Especially in the latter case I would really like to see what is going on. 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] Driver for UPS Eaton 9130
Citeren Attila Csontos attila.cson...@r-sys.sk: Hi Kjell and Arnaud, I was trying Kjell's command (/path/to/bcmxcp -DD -a pw9130 -u root) and I have got this output: [...] After that driver finished with Segmentation Fault (core dumped). No core file in current directory. If you care to attempt to debug what is going in, it might help to run the above command through 'valgrind'. This will allow examining what causes the segmentation fault. This could be bcmxcp driver specific or (worse) be caused by an error in the main driver core functions. Especially in the latter case I would really like to see what is going on. 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] blazer_usb - short reply
Citeren Andrew Zabolotny z...@homelink.ru: [ippon] driver = blazer_usb port = auto vendorid = 06da productid = 0003 desc = Ippon Smart Winner 3000 This vendorid and productid are already supported out-of-the box. Specifying them in the configuration should only be done for devices that are not (yet) supported. If I run blazer_usb -a ippon -D I get the following: debug level is '5' Checking device (06DA/0003) (002/011) - VendorID: 06da - ProductID: 0003 - Manufacturer: unknown - Product: USB UPS - Serial Number: unknown - Bus: 002 Trying to match device Device matches failed to claim USB device: could not claim interface 0: Device or resource busy detached kernel driver from USB device... The above is normal. Apparently the kernel already configured a driver for this device and we need to detach that driver before we can use the device. Trying megatec protocol... send: Q1 read: (218.7 218.7 218.7 020 50.0 0110 54.8 1000 send_to_all: SETINFO input.voltage 218.7 send_to_all: SETINFO input.voltage.fault 218.7 send_to_all: SETINFO output.voltage 218.7 send_to_all: SETINFO ups.load 20 send_to_all: SETINFO input.frequency 50.0 send_to_all: SETINFO battery.voltage 110.00 send_to_all: SETINFO ups.temperature 54.8 send_to_all: SETINFO beeper.status disabled send_to_all: SETINFO ups.type offline / line interactive send_to_all: SETINFO ups.status OL Status read in 1 tries Looks good. Supported UPS detected with megatec protocol send: error sending control message: Connection timed out blazer_rating: short reply Rating read 1 failed This doesn't look good. Apparently, your UPS doesn't understand the command to read the ratings from it. Some devices are brain dead and will not answer anything after that, so you should configure the driver to skip the detection of the ratings (see 'man 8 blazer' on how to do that). You may want to skip reading the vendor information as well, since that most likely will result in the same mess. Checking device (06DA/0003) (002/011) - VendorID: 06da - ProductID: 0003 - Manufacturer: unknown - Product: unknown - Serial Number: unknown - Bus: 002 Trying to match device Device does not match - skipping Checking device (/) (002/001) ... here it goes over all USB devices, despite the fact that I have pointed the vendor/product ids in the config ... This is not how the detection mechanism works. It will walk trough all USB devices until one matches. But apparently, your UPS doesn't listen to us anymore. [...] send_to_all: SETINFO ups.vendorid send_to_all: SETINFO ups.productid This is a bug that has been fixed in the SVN trunk already. 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] Weird Load and Battery Temp Readings
Citeren Bob Blackwell rc.blackw...@yahoo.ca: If you post debug output, make sure to include the report descriptor, which would be the most valueable part, together with the initial dump of the variables. The dump you posted only contained the report descriptor, however the initial dump of the data was missing. We need both to get an idea what is going on. The report descriptor itself looks good (I was able to successfully parse it). 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] Weird Load and Battery Temp Readings
Citeren Bob Blackwell rc.blackw...@yahoo.ca: The dump you posted only contained the report descriptor, however the initial dump of the data was missing. We need both to get an idea what is going on. The report descriptor itself looks good (I was able to successfully parse it). Sorry about that. Here's more! OK, that looks good too, so the problem must be in the calculation of the unit exponent (probably got something to do with erroneous type casting). I updated the SVN trunk with some more debugging info. Can you check out if this solves this issue? 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] blazer_usb - short reply
Citeren Alexander I. Gordeev lasa...@lvk.cs.msu.su: I've just commited a fix for the blazer_usb driver. I'm still trying to fix megatec_usb also. There is a very odd and interesting problem which I want to resolve. I've reverted your fix. This breaks other devices where we need to read until '\r' and will continue to report nonsense infinitly afterwards. So we probably should create a separate subdriver for this device that needs reading until timeout. 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] blazer_usb - short reply
Citeren Arjen de Korte nut+us...@de-korte.org: I've just commited a fix for the blazer_usb driver. I'm still trying to fix megatec_usb also. There is a very odd and interesting problem which I want to resolve. I've reverted your fix. This breaks other devices where we need to read until '\r' and will continue to report nonsense infinitly afterwards. So we probably should create a separate subdriver for this device that needs reading until timeout. Note that I'm not convinced that reading until a timeout is received is a good idea at all. So maybe we should just create a separate subdriver here and allow people to override the build in automatic subdriver selection (which is possible for blazer_usb). As for the OP's problem, I'm not convinced that your patch would work. This could also very well be a problem with the UPS not understanding that we want to read the rating (and locking up afterwards). So unless we get a reply on this question, I don't think making any modifications at all would be a good idea. After all, it looks like the OP also tried the megatec_usb which didn't work either, although this one does read until timeout (so this probably isn't the problem here). 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] Weird Load and Battery Temp Readings
Citeren Bob Blackwell rc.blackw...@yahoo.ca: OK, that looks good too, so the problem must be in the calculation of the unit exponent (probably got something to do with erroneous type casting). I updated the SVN trunk with some more debugging info. Can you check out if this solves this issue? Will do however it may be a week or so before I'm able to report back as I'm relying on another party to build and package an installer. Thanks to excellent support from the DNS323 group, specifically a member name fonz, I was able to obtain and install the latest update. I'm please to say that recent changes have corrected the problem. Following is DEBUG output; [...] Entering libusb_get_report Report[get]: (3 bytes) = 1e cf 0b PhyMax = 0, PhyMin = 0, LogMax = 65535, LogMin = 0 Unit = 00010001, UnitExp = -1 Unit Exponent = -1 hid_lookup_path: 00840004 - UPS hid_lookup_path: 00840012 - Battery hid_lookup_path: 00840036 - Temperature Path: UPS.Battery.Temperature, Type: Feature, ReportID: 0x1e, Offset: 0, Size: 16, Value: 302.30 Seems very reasonable. [...] Entering libusb_get_report Report[get]: (3 bytes) = 2c e6 00 PhyMax = 0, PhyMin = 0, LogMax = 65535, LogMin = 0 Unit = , UnitExp = -1 Unit Exponent = -1 hid_lookup_path: 00840004 - UPS hid_lookup_path: 0084001c - Output hid_lookup_path: 00840035 - PercentLoad Path: UPS.Output.PercentLoad, Type: Feature, ReportID: 0x2c, Offset: 0, Size: 16, Value: 23.00 And same here. Short of a couple of excess '\n' characters in the debugging output I added, I think we can conclude that the recent changes indeed fixed the problem. Thanks for your cooperation in solving this. We have similar errors before, but in those cases reporters were either unable of unwilling to dig deeper into this. These changes will be available in the next stable version of NUT. 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] blazer_usb - short reply
Citeren Alexander I. Gordeev lasa...@lvk.cs.msu.su: First of all, IMO you should trust me more because I now have an 06da:0003 Ippon device. It's not that I don't trust you. I´ll take your word for it that reading until timeout is needed for the 06da:0003 if you say so. You made exactly the same mistake as I did when I started messing with the 'agiler' subdriver in megatec_usb.c a while ago, breaking it in the process. If you think/know that in order to support a device, behavior needs to be changed, you should create a separate subdriver instead of modifying an existing one that has already proved to work for at least the author. Therefor I have renamed my version of the 'phoenix' subdriver to 'cypress' and added yours as the new 'phoenix' subdriver. I prefer not reading beyond the '\r' character for the 'cypress' subdriver, instead of waiting for a timeout that will never come for some devices and fill the supplied buffer with garbage until full. 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] megaline 5000, battery charge
Citeren Alexey Konokhov a.konok...@gmail.com: I have Megaline 5000 UPS, which I need to monitor via RS232 interface. I'm using metasys driver, and everything is Ok, but I can't see battery charge. From command line and cgi-interface I can see battery voltage, input and output voltage and load of UPS in %. But there is nothing about battery charge and remaining time (when on-battery). Is there any chance to see it? Well, looking at online documentation for this device, it looks like the UPS is able to report these values on the build in LCD display. In most cases, this means that you can also read this from the device through the monitoring interface. The bad news here is, that currently the metasys driver doesn't seem to handle this in any way. Worse, short of some general fixes regarding changes in NUT, nobody has touched this driver for at least four years. I'm not even sure if the original author of this driver is still involved with NUT and/or still has access to a device for testing. I've put him on the CC list anyway, so we'll see if he is willing/able to add this to the driver. 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] MUSTEK PowerMust 3000 NetGuard RM
Citeren Igor R i...@kaba.org.ua: We are using the equipment MUSTEK PowerMust 3000 NetGuard RM. That is using Megatec protocol. But unfortunately not all the data can be viewed correctly when dumping from utility upsc. For example: upsbox# upsc mus...@localhost battery.voltage: 108.00 battery.voltage.nominal: 96.0 driver.name: megatec driver.parameter.pollinterval: 2 driver.parameter.port: /dev/cuad0 driver.version: 2.4.1 driver.version.internal: 1.6 input.frequency: 50.0 input.frequency.nominal: 50.0 input.voltage: 227.0 input.voltage.fault: 227.0 input.voltage.maximum: 228.8 input.voltage.minimum: 224.1 input.voltage.nominal: 220.0 output.voltage: 227.0 ups.beeper.status: enabled ups.delay.shutdown: 0 ups.delay.start: 2 ups.load: 30.0 ups.mfr: unknown ups.model: unknown ups.serial: unknown ups.status: OL ups.temperature: 60.6 ups.type: standby Nothing wrong with the above. What data that isn't correct in your opinion are you referring to? Also when starting NUT program we can see the following messages: upsbox# /usr/local/etc/rc.d/nut start Network UPS Tools - UPS driver controller 2.4.1 Network UPS Tools - Megatec protocol driver 1.6 (2.4.1) Megatec protocol UPS detected. This UPS has an unsupported combination of battery voltage/number of batteries. Cannot calculate charge percentage for this UPS. Starting nut. You need to read the documentation and FAQ first, before asking for help. How to make the above messages disappear is described in 'man 8 megatec'. As far as we understand this model of the equipment is not being supported currently. Could you please inform me who do I need refer to to add this equipment to the list of supported ones? You're doing a fine job now, the mailing list is the first place you go to when asking for help. 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] Cabac UPS-1700DV2
Citeren mick mickh...@bigpond.net.au: KDE Info Centre reports the UPS as: STD UPS MON V1.0 Class 0 ((Defined at Interface level)) Subclass0 Protocol0 USB Version 1.00 Vendor ID 0x1 (Fry's Electronics) Product ID 0x0 This VendorID:ProductID is completely bogus, although we've seen it before. Your UPS *might* be supported by the megatec_usb and/or blazer_usb drivers. See 'man 8 megatec_usb' and 'man 8 blazer' respectively. 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] Trouble with PowerMan UPS
Citeren Yevgeny Kosarzhevsky y...@pisem.net: I get a trouble using nut with PowerMan Back Pro N 1400 Plus [...] I have tried it on win xp with WinStar Pro and it works just fine. The cable and UPS are new. Any advice? Read 'man 8 blazer' and try the 'blazer_ser' driver (in that order). 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] Belkin F6C750-AVR Nut Driver for Linux
Citeren xqa xqa xq1xq1...@yahoo.com: [...] As you can see the F6C750-AVR appears to be megatec protocol. Does anyone know what I need to do to control how I can control the Belkin F6C750-AVR UPS? Have I missed some config? You probably didn't read the README and INSTALL files, where we document this. You've alread done the most difficult part of it (find the appropriate driver for your UPS), so at least you can use NUT to monitor/control your UPS. Most likely however, your distribution will already provide some way to install and run NUT, so you'd better check that out first. 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] Belkin F6C750-AVR Nut Driver for Linux
Citeren Richard Chapman rchap...@aardvark.com.au: I am using a very similar Belkin UPS with nut 2.2.0 and Centos 5.3. No, you're not. Belkin devices come in different flavors, depending on the manufacturing date. If you look in the drivers.list, you'll see that some identical Belkin models require different drivers. Fortunately they use different vendorid:productid combinations, so it isn't hard to tell them apart when connected. I can't find my exact model number but I think mine is the 1200va version similar to yours. I also tried installing the supplied Linux drivers - but gave up. I also gave up on the serial connection. The same goes for the serial ports. For newer models, we don't support that. But I have got it working with the usb connection - and it works pretty well. There is a generic USB driver which works fine with this UPS - with somewhat limited but adequate functionality for my purposes. It may be all your UPS supports. 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] upsmon shutdown based on Time since power fail.
Citeren Richard Chapman rchap...@aardvark.com.au: This sounds like one way to do it. If I do it this way - do you know whether the file: /etc/killpower will be created before the shut-down is issued (as it would if the battery low event occurs). If not - the UPS may not be shut down - and therefore the system may not start up again if the power returns before the battery is completely flat. I guess if the flag file isn't created - then we could run a short script to create it - then issue the shut-down Does that sound right to you? Indeed - if we do write a short script - we could do the delay in the script - somehow test whether we are still on battery - and if so - issue the shut-down immediately. Don't do this. As written in the FAQ, in some cases you may wish/need to use 'upssched' to start shutting down your systems before the UPS indicates the battery is low. In that case, you probably want to call 'upsmon -c fsd' instead, which will initiate a shutdown on the upsmon master (in your case, your server). This means that you will have to configure the upsmon on the server (FINALDELAY) to allow for enough time for your clients to shutdown. This will put your master at risk in case of repeated power failures however, so don't overdo this. 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] APC Smart UPS 900i
Citeren Rene Bartsch m...@bartschnet.de: Command: /lib/nut/apcsmart -a su900i -D - snip - Network UPS Tools - APC Smart protocol driver 2.00 (2.4.1) APC command table version 2.0 debug level is '5' send_to_all: SETINFO ups.mfr APC Attempting firmware lookup Attempting to contact older Smart-UPS version Firmware: [7QI] That's all we need for now. I've just added support for this version, assuming that it is similar to the Smart UPS 900 firmware [7TD] we already support. We have confirmed that this is the case for the 600 and 1250 models, so this probably goes for the 900 as well. I've added support for all variations of the [678][QT][DI] models now, so if you grab the latest version from the SVN trunk, you should be fine. Please let us know if this works for you. 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 ala...@caerllewys.net: babylon4:root:/opt/nut:24 start Network UPS Tools - UPS driver controller 2.4.1 Network UPS Tools - BCMXCP UPS driver 0.21 (2.4.1) RS-232 communication subdriver 0.17 Connected to UPS on /dev/tty00 with baudrate 19200 OK, the driver is running, so this is not the problem. babylon4:root:/opt/nut:25 # sbin/upsd Network UPS Tools upsd 2.4.1 listening on 127.0.0.1 port 3493 listening on ::1 port 3493 /opt/nut/var is world readable Connected to UPS [tokamak]: bcmxcp-tokamak Maximum number of connections limited to 256 [requested 1024] Weird, apparently your system has a limited number of file descriptors available. I have a feeling that this is not a standard operating system. babylon4:root:/opt/nut:26 # bin/upsc toka...@localhost Error: Connection failure: Connection refused For whatever reason, you can't connect to localhost. I've never seen this before. The only thing I can imagine now is that some kind of policy exists that doesn't allow you connect through localhost because this is OS is running as a guest on top of another system. 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 ala...@caerllewys.net: babylon4:root:/opt/nut:25 # sbin/upsd Network UPS Tools upsd 2.4.1 listening on 127.0.0.1 port 3493 listening on ::1 port 3493 /opt/nut/var is world readable Connected to UPS [tokamak]: bcmxcp-tokamak Maximum number of connections limited to 256 [requested 1024] Weird, apparently your system has a limited number of file descriptors available. I have a feeling that this is not a standard operating system. I was a little puzzled by that myself. It's Solaris 10 x86 running on a pretty substantial box, it shouldn't be an OS limitation. 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). 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. For whatever reason, you can't connect to localhost. I've never seen this before. The only thing I can imagine now is that some kind of policy exists that doesn't allow you connect through localhost because this is OS is running as a guest on top of another system. Nope, this is not a client OS or vhost. This is the global zone of a Solaris 10 machine, and as you can see, the above was running as root. This all makes sense now. The server is not running. BTW, upsd.conf is default with everything commented out, which should result in listening on everything: # This defaults to the global IPv4 listening address and port 3493. You # may specify each interface you want upsd to listen on for connections, # optionally with a port number. We need to change this. This used to be the case in older versions, but we now default to a (safer) localhost only. [...] Could this be because something is limiting it to 256 connections? (Not that I'm ever going to need even a tenth of that 16 connections would be more than I'm ever going to need to use.) I'm wondering whether I should go tweak the source to request only 256 connections (or even 128) and see if upsd still dies on startup. Yes, see a couple of lines down in upsd.conf (no need to tweak the sources for that). 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 ala...@caerllewys.net: 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
Re: [Nut-upsuser] APC Smart UPS 900i
Citeren Rene Bartsch m...@bartschnet.de: 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] APC Smart UPS 900i
Citeren Rene Bartsch m...@bartschnet.de: I just reinstalled a current SVN and model is Smart-UPS, now. :) Good. But I also realized that upsrw can only set battery.date and ups.id but nothing else. I'd really appreciate to have the capability to set ups.test.interval at least. ;) Maybe older devices don't support this, or the author of this driver didn't know about them. I really don't know. Please post the output of this driver when running it in debug mode like /path/to/apcsmart -a su900i -D to see if it reveals anything and someone steps up to check this. I neither own nor have any interest in adding these features, so this is where I step back. Given the age of your hardware, I really doubt it is worth the time and effort to dig into this, unless you have plenty of free time on your hands. P.S.: What means Please keep list traffic on the list in your signature? To do just what you do - keep the list traffic on the list and don't take it off-list. I usually don't respond to replies sent in private, unless a consulting fee is involved. 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] Can't connect to UPS [mustek] (megatec-mustek): No such file or directory
Citeren Vedran Furač vedr...@vedranf.mine.nu: Where is megatec-mustek file? It should be created by the driver, which apparently isn't running. Either it isn't started at all, fails to detect the UPS or isn't running with the proper permissions. [snip] dstate_init: sock /var/run/nut/megatec-mustek open on fd 5 There is the driver socket to which the server connects. Since this is created without problems, I suspect that you forgot to start the driver in your earlier attempts. 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] Belkin support?
Citeren Gene Heskett gene.hesk...@gmail.com: That seems to work, as in doesn't exit even if I run a second invocation of usbhid-ups -a myups, both show up at the bottom of htop's listing, and both responded to a kill from htop. The output was: [r...@coyote /]# usbhid-ups -a myups Network UPS Tools: 0.29 USB communication driver - core 0.33 (2.2.2) Using subdriver: Belkin HID 0.11 But no other output was seen. They ran for about 2 or 3 minutes. Since this ups outputs a continuous string of status info, there must be something doofy in the connection. I'll check when I am awake, ERR_NOTSUFFICIENT_CAFFEINE right now. This is right what we expect. You clearly first need to read up on the README and INSTALL files, since these will explain how to set this up. Looking at the above, it is quite clear that your UPS is indeed supported, but you didn't set NUT up properly yet. We have been thinking about setting up a configuration wizard, but so far we're lacking the resources to do this. Sorry about that. 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] Slave as master
Citeren Dr. Madhurjya P. Bora mpb...@yahoo.com: I need to set up machine as slave which will act as a master to some subordinate clients. The machine is question is a master node a parallel cluster which I want it to act as a master for the computing nodes but set itself as a slave with a master exclusively controlling the UPS elsewhere. Is this possible and how? The question is, why do you want/need this? Please be as specific as possible about the shutdown scenario you're trying to setup. 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] Slave as master
Citeren Rob MacGregor rob.macgre...@gmail.com: I have a similar question to this as well, in that I have my server set up using NUT with a SOLA-330 (working nicely!) and my desktop is using an APC BackUPS-300 (this model has no serial/USB comms) as the SOLA APC are rated the same, I was wanting my server to send a broadcast packet across my LAN to force all PC's (that are still powered by UPS's) to shut down... (I have a third desktop without a UPS at this time! and in the event of a power outage this will already be down!) Is this possible to be done? if so, where can I find such information? A machine can be a master for an UPS that it isn't powered by. The documentation has covered this for at least 5 years now ;) There seems to be a lot of confusion about the meaning of 'master/slave' for 'upsmon'. The major difference between 'upsmon' running as master or as a slave, is that when it is a master for a certain UPS, it can command it to shutdown. Whether or not it is powered by said UPS is of no importance for that (although in most cases, both master and slaves will be). See also 'man 8 upsmon' for more information on this. The second thing is, that there is no need for a 'upsmon' to be powered by a UPS in order to run. It is quite possible, to listen in on a UPS and shutdown a system if the UPS is shutting down. See the explanation of MONITOR and MINSUPPLIES in 'man 8 upsmon.conf'. 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] Tripplite Smart1500
Citeren Charles Lepple clep...@gmail.com: ups.status: The ups.status value is problematic - it should include at least OL or OB. Not sure whether it is due to Protocol 4-related changes, or the aforementioned timeout. The above is due to a problem with calculation of the size of reports in libhid.c that was fixed more than a year ago. This fix requires nut-2.2.2 or newer. For many USB devices, anything earlier than that may mean that they run into this limitation (that existed since we first released newhidups by the way). 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] Tripplite Smart1500
Citeren Charles Lepple clep...@gmail.com: The above is due to a problem with calculation of the size of reports in libhid.c that was fixed more than a year ago. This fix requires nut-2.2.2 or newer. For many USB devices, anything earlier than that may mean that they run into this limitation (that existed since we first released newhidups by the way). Are you sure this applies to pseudo-HID devices too? I agree that a newer version of NUT will include a version of tripplite_usb that should work better, but that driver only uses a few libhid.c functions for matching devices. I stand corrected, you're absolutely right. Something similar happens for the Tripplite HID PDC devices, but obviously this is not the case here. 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] UPS does not want to power off itself
Citeren Anton E. Panchenko p...@chernigovka.org: [...] upsshed-cmd #!/bin/sh MSG=The UPS is running on battery about 2 minutes, doing force shutdown case $1 in fsd) logger -t upssched-cmd $MSG /sbin/upsmon -c fsd ;; *) logger -t upssched-cmd ERROR!! $0 Unrecognized command: $1 ;; esac Assuming the message is logged (and you thereby having confirmed that indeed the 'fsd' timer is elapsed, the problem is that upssched will run with the same UID as upsmon (that started this timer). In that case, the command /sbin/upsmon -c fsd will also run as this user. So in order to test this, you must make sure that the above command when running as a non-privileged user will shutdown your system or you must run upsmon as a privileged user. You might be able to do something similar by allowing this user to use 'sudo' for just this command. Choose your poison. 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] Is any ideas about Ippon smart power 2000?
Citeren vk v...@union-metall.ru: Hi friends! It is not any answer to my previous letter about problem with nut 2.4.1 and ippon smart power 2000 UPS with megatec_usb driver. Maybe any additional information needed? Please help, any required info i get. Please post the output of /path/to/megatec_usb -u root -DDD -a IPPON here. If this fails to connect to your UPS, chances are that you haven't prepared your kernel to allow the userspace driver to bind to the USB device. In that case, search the archives. 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] Is any ideas about Ippon smart power 2000?
Citeren Alexander Gordeev lasa...@lvk.cs.msu.su: Please post the output of /path/to/megatec_usb -u root -DDD -a IPPON here. If this fails to connect to your UPS, chances are that you haven't prepared your kernel to allow the userspace driver to bind to the USB device. In that case, search the archives. It's here: http://lists.alioth.debian.org/pipermail/nut-upsuser/2009-June/005162.html This is missing the '-u root' option. We need that, to rule out permissions problems. Seems to me it's the usual problem with USB quirks in FreeBSD. I'm not a FreeBSD user so I can only guess. I agree. I'm not a FreeBSD user either, but since the VID:PID should be supported, it's either that or a permissions problem. 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] Premature end of script headers: upsimage.cgi
Citeren benjamin thielsen bthiel...@safarivideonetworks.com: working voltage graph: [ups2] driver = usbhid-ups port = auto [...] battery.voltage: 27.7 battery.voltage.nominal: 24.0 This looks normal. non-working voltage graph: [ups4] driver = snmp-ups port = ups4 community = xx snmp_version = v1 pollfreq = 5 [...] battery.voltage: 55.00 battery.voltage.nominal: 0.00 But here we have located the problem. A 'battery.voltage.nominal' equal to zero will mean that the calculated 'battery.voltage.minimum' and 'battery.voltage.maximum' will both be zero. This results in a divide by zero error in the range calculation. You can work around this by adding override.battery.voltage.nominal = 48 in 'ups.conf' for these drivers. This will make them ignore the reported value from the UPS and use the correct nominal value. You can also set default.battery.voltage.minimum = 38.4 default.battery.voltage.maximum = 55.2 to preset the minimum and maximum voltage range of the battery, since neither are reported by the UPS. What remains is the question if this is a problem in the snmp-ups driver or the UPS. I honestly don't know. 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] Premature end of script headers: upsimage.cgi
Citeren benjamin thielsen bthiel...@safarivideonetworks.com: aha - thank you, that seems to have done the trick. i suppose that dividing by zero would also explain the floating point error. Yes. That tipped me off that there might be something wrong in the values reported by the UPS. regarding the values you've specified above for the override and defaults - how are those determined? Your UPS reports a battery voltage of 55 V. Assuming this is correct, this would be right what you'd expect for a 48 V nominal lead acid battery (24 cells) that is fully charged (depending on the vendor, 2.27 - 2.30 V per cell). The minimum cell voltage is where the UPS shuts down to protect the batteries for deep discharge (1.60 - 1.80 V per cell). If 'battery.voltage.nominal' is provided, both will be calculated automatically if not reported by the driver, but I'd rather make this explicit in the configuration. What remains is the question if this is a problem in the snmp-ups driver or the UPS. I honestly don't know. well, if the output of snmpwalk is any indication, it appears that snmp-ups is accurately passing on values: snmpwalk -v1 -c xx -m '/usr/share/snmp/mibs/powernet391.mib' ups4 .1.3.6.1.4.1 | grep -i nominal PowerNet-MIB::upsAdvBatteryNominalVoltage.0 = INTEGER: 0 That sucks, but this also explains the other weird values that are reported. I noticed quite a couple of firmware updates for this UPS on the APC site. It might be worthwhile to check if this fixes things. 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] Is any ideas about Ippon smart power 2000?
Citeren vk v...@union-metall.ru: Hi! There is continue of my story with Ippon smart power 2000 and nut, i'm enable usb in kernel and nut give following information: gate# cat ups.conf [IPPON] driver = megatec_usb port = /dev/ugen0 vendorid = 0665 productid = 5161 subdriver = phoenix desc = Ippon Smart power 2000 - [...] At least you're able to talk to the UPS now. Could you please retry with the 'blazer_usb' driver? I'm not sure if this will fix things, but since I wrote this one, I'm more familiar with its operation. You should only have to change the line driver = blazer_usb and you should be up and running. If this works, make sure to checkout 'man 8 blazer' to get an idea on all the features that are supported by this driver. 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] Accurate battery reports? (HP R3000 XR)
Citeren Jon Bendtsen jbendt...@laerdal.dk: I have a HP R3000 XR UPS which NUT never says is at 100% battery. It seems stuck in 98 or 99 . something percentage. Please mention the driver you're using when asking for help. How accurate should i expect the reports to be? All my other UPSes has been and is at 100%, even those i have retired. Most drivers will report the value received from the UPS directly so you would have to ask the vendor/manufacturer about the accuracy of the readings. Some drivers attempt to calculate the battery charge themselves when the value is not reported by the UPS and generally there will be a note in the man page about which algorithm is used then. For basically all values that are reported, you should be looking at changes and trend lines, rather than absolute values. A UPS is not a measuring instrument and more often than not, the resolution of readings doesn't reflect the accuracy. 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
[Nut-upsuser] CyberPower OP- and PR-series UPS (230 V version)
To be able to calibrate the voltage conversions for the powerpanel driver (binary mode) I need some startup logs for the PowerPanel Plus (Windows) program that is provided by CyberPower. Preferably logs created with the following tool: http://technet.microsoft.com/en-us/sysinternals/bb896644.aspx Note that for the moment I only need the logs for the 230 V versions of these devices, we have something available for the 120 V versions. I need about 30 seconds worth or logs after startup of the program. 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] Problem with APC SMART UPS 1000 (USB)
Citeren Sergey s_...@mail.ru: [...] But, to switch off the electric power After 20 min: -- $upsc usb ..skip... battery.charge: 100 battery.temperature: 36.8 battery.voltage: 23.9 input.voltage: 0.0 output.voltage: 220.4 ups.load: 24.7 ups.status: OL ...skip... -- The ups.status and battery.charger have not changed the value. battery.voltage, ups.load, battery.temperature adequately react. After restoration electric power: -- $upsc usb ..skip... battery.charge: 52 battery.temperature: 39.1 battery.voltage: 26.2 input.voltage: 217.4 output.voltage: 217.4 ups.load: 26.6 ups.status: OL ...skip... -- The battery.charge and input.voltage show correct values. Apparently, your UPS doesn't update the reported battery charge, until the power is restored. There is nothing we can do about that. The only thing that worries me here a little, is that the status doesn't change from OL to OB when the mains is interrupted. This means that there may be a conflict between the two HID paths that feed this status: UPS.PowerSummary.PresentStatus.ACPresent UPS.PowerSummary.ACPresent You could help diagnosing this, buy running the driver in debug mode through /path/to/usbhid-ups -DD -a upsname Disconnect the mains and let it run until the load is switched off. We're only interested in the above two HID paths, so please only post the relevant lines from the output. P.S. Probably the driver not truly reads out a condition my ups. It does, otherwise the other values wouldn't change either. 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] Problem with nut 2.4.1 Ippon 2000 Smart power on FreeBSD
Citeren vk v...@union-metall.ru:
gate# /usr/local/libexec/nut/blazer_usb - -a IPPON
Network UPS Tools - Megatec/Q1 protocol USB driver 0.03 (2.4.1)
debug level is '4'
Checking device (0665/5161) (/dev/usb1//dev/ugen0)
- VendorID: 0665
- ProductID: 5161
- Manufacturer: Cypress Semiconductor
- Product: USB to Serial
- Serial Number: unknown
- Bus: /dev/usb1
Trying to match device
Device matches
Trying megatec protocol...
send: Q1
read: timeout
blazer_status: short reply
Status read 1 failed
send: Q1
read: timeout
blazer_status: short reply
Status read 2 failed
send: Q1
read: timeout
blazer_status: short reply
Status read 3 failed
Trying mustek protocol...
send: QS
read: timeout
blazer_status: short reply
Status read 1 failed
send: QS
read: timeout
blazer_status: short reply
Status read 2 failed
send: error sending control message: Input/output error
blazer_status: short reply
Status read 3 failed
Trying megatec/old protocol...
Checking device (0665/5161) (/dev/usb1//dev/ugen0)
- VendorID: 0665
- ProductID: 5161
- Manufacturer: Cypress Semiconductor
- Product: USB to Serial
- Serial Number: unknown
- Bus: /dev/usb1
Trying to match device
Device matches
send: D
read: timeout
blazer_status: short reply
Status read 1 failed
send: D
read: timeout
blazer_status: short reply
Status read 2 failed
send: D
read: timeout
blazer_status: short reply
Status read 3 failed
No supported UPS detected
Support for libusb is 'experimental' at best in FreeBSD and depending
on the version you're using, 'unusable'. You may try if adding a small
delay between sending a command and reading back the reply helps (YMMV):
--- trunk/drivers/blazer_usb.c (revision 1861)
+++ trunk/drivers/blazer_usb.c (working copy)
@@ -72,6 +72,7 @@
upsdebugx(3, send: %.*s, (int)strcspn(tmp, \r), tmp);
memset(buf, 0, buflen);
+ usleep(30);
for (i = 0; (i = buflen-8) (strchr(buf, '\r') == NULL); i += ret) {
If your UPS also has a serial port available, it is probably more
reliable to use a USB to serial converter (that is supported by the
kernel) than attempting to run a user space program that attempts to
handle USB through libusb.
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] Problem with nut 2.4.1 Ippon 2000 Smart power on FreeBSD
Citeren vk v...@union-metall.ru:
Support for libusb is 'experimental' at best in FreeBSD and depending
on the version you're using, 'unusable'. You may try if adding a small
delay between sending a command and reading back the reply helps (YMMV):
--- trunk/drivers/blazer_usb.c (revision 1861)
+++ trunk/drivers/blazer_usb.c (working copy)
@@ -72,6 +72,7 @@
upsdebugx(3, send: %.*s, (int)strcspn(tmp, \r), tmp);
memset(buf, 0, buflen);
+ usleep(30);
for (i = 0; (i = buflen-8) (strchr(buf, '\r') == NULL);
i += ret) {
If your UPS also has a serial port available, it is probably more
reliable to use a USB to serial converter (that is supported by the
kernel) than attempting to run a user space program that attempts to
handle USB through libusb.
I try add usleep(30); to blazer_usb and it is not helps. Maybe
you can tell how use USB to serial converter? And which?
I don't know, I'm not an expert on FreeBSD.
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] Any word on when the ietf mib will be fixed for liebert?
Citeren Maurice Volaski mvola...@aecom.yu.edu: This mib used to work, so is there a way to go back to the version prior to this one without downgrading the whole package? When did this stop working (from which version to nut-2.4.1 did you upgrade)? The last changes to the IETF are made almost two years ago. Also, a dump of 'upsc' would be helpful, since I doubt that the errors you're seeing are fatal (they look more like warnings to me). 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] Any word on when the ietf mib will be fixed for liebert?
Citeren Maurice Volaski mvola...@aecom.yu.edu: This mib used to work, so is there a way to go back to the version prior to this one without downgrading the whole package? yes, only take the snmp-ups driver from the previous working release. 2.2.2 and 2.0.5 also complain but with fewer errors. Please don't mistake warning messages with (fatal) errors. Starting with nut-2.4.0, these messages should only be displayed in debug mode, so I'm surprised you're seeing them in nut-2.4.1. If you're not a developer, you should *not* run any part of NUT in debug mode unless asked for. Don't draw conclusions about *any* debug message if you're not familiar with the code base. Upon startup, the snmp-ups driver will query the UPS for all the OID's the driver supports. The ones which are not supported by the UPS, will generally result in an error message from the NetSNMP library that is used. There is nothing we can do about that and it is *not* an error. Generally speaking, over time we will add more OID's to the MIB's, which means that you may see more of these 'error messages' after an update. This is harmless. It just means that your UPS uses only a subset of the full IETF MIB (which is not unusual at all). [...] Anyway, now that the script is starting, I'm seeing failed - got [ERR ACCESS-DENIED] errors from upsmon, and I don't know why. See 'man 8 upsd', 'man 5 upsd.conf' and 'man 5 upsd.users'. This is a configuration error. I noted that the configuration has changed. It seems ACLs and ACCEPT are no longer used and have been replaced with LISTEN, but I have set that. Indeed. Again, see the above manual pages. 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] Any word on when the ietf mib will be fixed for liebert?
Citeren Maurice Volaski mvola...@aecom.yu.edu: upslogx(LOG_ERR, [%s] %s: Error in packet: %s, This is a different message from what you reported before. These where logged with 'nut_snmp_get' in them and these lines should now be gone (unless running in debug mode 2 or higher). What message do you think I posted? It was this one and it has the Error in packet: [upswallleft] nut_snmp_get: 1.3.6.1.2.1.33.1.4.4.1.4.0: Error in packet: (noSuchName) There is no such variable name in this MIB. I stand corrected, I looked at a different location where an identical (!) message is logged. Gotta change that one, because that's downright confusing. A fixed version is now available in the SVN trunk, that will correct this. [...] Where exactly do see any mention of debug or warning? Nowhere. You're absolutely right. [...] No, there was only one set of messages that prompted me to post and they were reported as errors and they are indeed being continuously output to the system log. Well, we do use rate limiting here (and will log only once every 100 errors after the initial 10), but with the given amount of queries (and failing), I agree this will still be quite often. Unless what I expected, we do keep querying these non-existent OID's, so the better solution would be to check on startup if they are supported by the UPS (like we do for the usbhid-ups in a similar fashion). I'm sorry for misleading you here. 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] Belkin F6C-1250-TW-RK is supported [patch]
Citeren David Mohr damaili...@mcbf.net: just wanted to let you know that I have two belkin F6C-1250-TW-RK UPSes which work just fine with nut. I made this small patch so that nut recognizes the usb device id. Thanks for the patch! I committed the change for the belkin-hid subdriver (the other file is a generated one). 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] pebcak or something else?
Citeren Svein Skogen (listmail account) svein-listm...@stillbilde.net: I've set up my ups solution with a dedicated box (laptop with its own powersupply) connected to the ups, and have set up upsmon.conf to use a customized script (SHUTDOWNCMD /usr/local/upsmonitor-files/shutdown.sh) that shuts down my ESXi boxes properly. However when ups power reaches the shutdown point, it seems that NUT promptly ignores the shutdown script and goes on to shut down the monitoring box instead. The laptop is running FreeBSD 7 stable (RELENG_7) with nut version 2.4.1 What have I done wrong? (in all respects except this, the NUT setup works) Read the section on POWER VALUES in 'man 8 upsmon'. You probably should assign the UPS a 'power value' of 0 (zero) on the laptop that is monitoring it (but isn't powered by it). 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] pebcak or something else?
Citeren Svein Skogen (listmail account) svein-listm...@stillbilde.net: Read the section on POWER VALUES in 'man 8 upsmon'. You probably should assign the UPS a 'power value' of 0 (zero) on the laptop that is monitoring it (but isn't powered by it). if it's a value of 0, will it still invoke the SHUTDOWNCMD? No and that's not what you want anyway if the box isn't powered by the UPS. Is there any particular reason why you can't run a upsmon client on the ESXi host OS? Usually this scales a lot better on multiple systems. Have a look at the NOTIFYCMD if you really want upsmon to run a script when a certain event triggers. 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] Usbhip-ups going wild
Citeren Antoine Gatineau antoine.gatin...@alcatel-lucent.com: I am facing some serious issues on customer's site. I looked around on the web and in the archives but didn't find anything. I hope you can help me. Here is my configuration : OS :RHES 4.7 NUT : 2.2.0 NUT-CLIENT : 2.2.0 Hardware : IBM x3250M2 (dual-core intel E3110) Here are the symptoms : After some time, the performance of my applications on this server began to drop with functional perturbation, so I took a look at the system and found that upshid-nut is taking around 15 to 20% of cpu time. Uptime is 20 days. And total cpu time used by usbhid-ups is 396 minutes. This seems hudge for a driver. In tried then to stop nut drivers and the system crashed and reset. Upgrade to a more recent version. There have been tons of changes in the usbhid-ups driver since nut-2.2.0 was released a little over two years ago. The older versions of this driver have serious performance issues (as well as bugs), which have been solved since. See the NEWS file for nut-2.4.1. 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] Accurate battery reports? (HP R3000 XR)
Citeren Jon Bendtsen jbendt...@laerdal.dk: NUT cgi started to report the battery at 100% without i remember doing anything. It could be that the UPS has performed an automatic battery test or runtime calibration in the mean time (which is not unusual for many higher end devices). Note that in general, you'd be interested in changes in the trend, rather than absolute values. This not only counts for battery charge, but for most other readings as well. If there is a significant change in a value without you doing something, it's worth investigating what causes it. 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
