similar to: upsdrvctl Unhandled Exception - hipups

Hello, I have encountered problems trying to set up nut to work with APC BackUps Pro CS connected over USB to an AMD64 machine running Debian. While apcupsd works fine with that device, whenever I start upsd I get the following messages in syslog: hidups[23159]: Startup successful upsd[23160]: Connected to UPS [apc1]: hidups-hiddev0 upsd[23161]: Startup successful hidups[23159]: Unhandled event:

Hi, I'm new to nut, just installed it. I configured it using the hidups driver to work with my APC BackUPS: # upsc apc350@localhost battery.charge: 100 battery.runtime: 885 battery.voltage: 13.5 driver.name: hidups driver.parameter.port: /dev/usb/hiddev0 driver.version: 2.0.0 ups.delay.shutdown: -1 ups.delay.start: 0 ups.load: 660 ups.mfr: American Power Conversion ups.model: Back-UPS CS 350

Hi, I am the next scenario: ############################################################################# SERVER SIDE? (64 bit architecture) ?############################################################################# Two Storage Machines with: HARDWARE DELL PE2900 III Intel Quad Core Xeon E5420 2,5Ghz, 2x6Mb cache, Bus 1333FSB RAM 4 GB FB 667Mhz (2x2Gb) 8 HDD 1 TB, Near Line SAS 3,5"

I'd like to submit a patch to the 'hidups' driver. I'm a bit new to open-source development model, so I hope I'm not committing a faux paus by just posting it here. I did verify that the problem still exists (by source code inspection) in the latest dev snapshot, which is nut-2.0.3-pre2. I'm using nut-2.0.2 myself. The problem is when I'm connecting to my APC

Hi! I've got a Mandrake 2006.0 machine and a APC Back-UPS Pro 500/1000/1500 (from lsusb). The Mandrake package version of nut is 2.0.1 and hidups actually detects the UPS, however I get loads of these: Sep 12 18:26:11 vader hidups[7658]: Ignoring x86 page event 0xff860080 (0) Sep 12 18:26:11 vader hidups[7658]: Unhandled event: 0x840058 (6) Sep 12 18:26:11 vader hidups[7658]: Unhandled

The change of the PID file names for the drivers causes some problems when upgrading from a previous version of NUT. The new 'upsdrvctl' will not be able to find the PID from drivers started by a previous version (since it looks for the new names only). To prevent shooting ourselves in the foot when upgrading, I slapped together a 'status' function in 'upsdrvctl' to see

Greetings. Though I got something working based on cobbling together from various examples.. I'm hoping that I could see others startup scripts as examples, to help improve my amateurish attempts.. Thanks for any examples.. (FYI.. running on RH9) John..

Hi, In Red Hat /etc/init.d/halt script, it expects upsdrvctl to be in /sbin rather than /bin which sounds normal considering the power of that command. If I move this file to sbin, this is what I get when invoking it: [root@serveur1.sassine.eu nut-2.0.5]# mv /bin/upsdrvctl /sbin/ [root@serveur1.sassine.eu nut-2.0.5]# which upsdrvctl /sbin/upsdrvctl [root@serveur1.sassine.eu nut-2.0.5]#

I can run "upsdrvctl start" and it starts fine. On computer boot, however, it doesn't start properly. I'm trying to find the logs which would give more detail, but I'm not sure where they are. I see no logs in /etc/nut or /var/log. I don't know if this helps, but it looks like there's a problem with the PID file generation: when I run "upsdrvctl stop"

Is there any reason why we couldn't pass the -D flags (counted by nut_debug_level) from upsdrvctl to the individual drivers? It seems a little strange to suggest to users that they should start the drivers with upsdrvctl normally, but then start them by hand for debugging. (If we want to debug upsdrvctl itself, we could use another flag for that, instead of -D.) -- - Charles Lepple

I did a test shutdown on a nut controlled UPS and it all went as expected except that when it got to: /usr/local/ups/bin/upsdrvctl shutdown Nothing happened. So the halt script went on and shut down the system. I waited a while but the UPS never turned itself off. Am I doing something wrong, or does this UPS not support this function? Thank you, David Mathog mathog at caltech.edu Manager,

Charles, When sorting out the library problem for shutdown, please also keep in mind that the shutdown scripts (at least those that I have encountered so far) insist on unmounting /dev/usb. This requires that libusb does not rely on its presence to do the reconnection for the shutdown. I don't know if this is a part of the definition of the functionality of libusb and if it can safely be

Hello, I had to increase slightly the maxstartdelay value to 60 instead of 45 as a work around, otherwise upsdrv and upsdrvctl are unable to start megatec_usb daemon at all. The strange thing is /lib64/nut/megatec_usb -DDDDDD -u nut -a mgeups runs without any problem and will recognize the value coming from the ups faster. Anyway, I don't understand why upsdrvctl does take so long to

Per the message printed by upsdrvctl: upsdrvctl start Network UPS Tools - UPS driver controller 2.6.3 Network UPS Tools - Generic HID driver 0.35 (2.6.3) USB communication driver 0.31 This TrippLite device (09ae:3016) is not (or perhaps not yet) supported by usbhid-ups. Please make sure you have an up-to-date version of NUT. If this does not fix the problem, try running the driver with the

Hi again, it seems to me that "upsdrvctl shutdown" fails to pass the "-u" flag to the driver. See drivers/upsdrvctl.c:shutdown_driver(), and compare to start_driver() in the same file. This has been so since ancient history (I checked back to 1.5.0), so there must be a reason, but I can't think of any. I have a good reason for passing "-u root": at the time

On 12/16/2013 09:06 AM, Charles Lepple wrote: > If you want, we can take a look at the output of the aforementioned udevd > command from your system. Please compress the output, and if the list bounces > it, I'll extract the relevant portion from the bounce message. > > I have a funny feeling we might either have a Debian-specific dependency on > 91-permissions.rules, or

Hi, /sbin/upsdrvctl is used as the near final step in /etc/init.d/halt to command the UPS to shut down power to the computer. On Fedora / Red Hat Enterprise Linux system, /usr can reside on its own partition. Drivers are linked to several libraries, but some of them lives in /usr/lib and this can be umounted when drivers are used. There are 16 libraries used on Fedora 11 system. This

I've installed nut on a Mac OS X machine (XServe running Mac OS X 10.3.9). It all seems to work fine except..... I can't figure out where to put the upsdrvctl shutdown command in order to get the ups to cut power after the computer shuts down. There doesn't seem to be any sort of script that gets run at shutdown time. Has anyone successful done this under Mac OS X? Can you

On Jan 27, 2008 11:07 AM, Arjen de Korte <nut+devel at de-korte.org> wrote: > > >> I also think we should not encourage people to post debug output before > >> consultation with a developer. Most of the time, providing useful debug > >> output requires more than just running the driver with an arbitrary > >> number of -D flags anyway. > > Well,

On Dec 14, 2013, at 4:19 AM, David C. Rankin wrote: > lsusb shows: > > Bus 004 Device 002: ID 0764:0501 Cyber Power System, Inc. CP1500 AVR UPS I am guessing that 'ls -l /dev/bus/usb/004/002' shows that the device node is not owned by the NUT gid? > Why doesn't > "upsdrvctl start" allow nut to find the UPS when it can find it without a > problem with