similar to: nut on Mac OS X. Where to put upsdrvctl shutdown?

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

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,

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

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]#

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

Using the HOWTO in http://keystoneit.wordpress.com/2006/09/25/network-ups-tools-nut-on-ubuntu/ I installed nut on an Ubuntu Edgy LAMP Server with an Eaton Powerware 5110 attached to it via usb. But nut fails to start properly (see the error message "Starting Network UPS Tools: (upsdrvctl failed) upsd upsmon" below). It then complains about communication with the UPS being lost ("UPS

On 12/14/2013 12:37 PM, David C. Rankin wrote: > I will test with the new ubs dev permission and report back. Thank you for your > help Charles. Charles, Setting uid:gid to root:nut on /dev/bus/usb/004/002 seemed to be the issue. The question now become how to automate this process so that the user isn't required to manually hunt down the usb dev and change gid to the nut gid? So

On 12/14/2013 07:20 AM, Charles Lepple wrote: > 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? > crw-rw-r-- 1 root root 189, 385 Dec

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

Is it possible to create a Startup Item for WEBrick? My startup item, named swu, works fine when I run it from the command line, just not when the computer is starting up. I''m wondering if some resources are missing for ruby to load at this point... or something. Here''s output from /var/log/system.log... Any suggestions would be appreciated. Aug 18 21:18:58 localhost

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

On 12/14/2013 02:06 PM, David C. Rankin wrote: > Charles, > > Setting uid:gid to root:nut on /dev/bus/usb/004/002 seemed to be the issue. > The question now become how to automate this process so that the user isn't > required to manually hunt down the usb dev and change gid to the nut gid? So > far, either manually setting the gid or hand-rolling the udev files to do the

On Dec 14, 2013, at 4:23 PM, David C. Rankin wrote: > Do you know if the problem with upsdrvctl being able to probe/connect to the > usb devices is the result of some default permission change in Linux in general. > It seems to me that since nut used to work right out-of-the-box, then all/most > distros must have had the default permissions on usb nodes set to 0666, where >

Running into a strange bug using the mongrel upload progress plugin handler, sitting in front of a simple mongrel. The bug appears on an old Xserve (mac OS X 10.3.9 powerpc), but not on my macbook pro, or even a generic 686 linux box. http://pastie.textmate.org/98341 The gist of the pastie above shows that attempts through the browser and curl are actually hitting the filesController, as

Q. What resource do readers recommend for referencing regarding best practices for form construction in Rails? I have the following situation: location_type of Locations may have one of five (5) possible codes. Presently I have these codes listed in a drop-down select constructed thusly: <p> <b>Location type</b><br /> <%= f.select :location_type,

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"

Greetings, When starting upsdrvctl with the hipups driver, I get the following "addtional" output Unhandled Event 0x840073 (0) Ignoring x86 page event 0xff86002 (0) Ignoring x86 page event 0xff860029 (34) It does not appear to be affecting anything in my tests so far.. (not finished with the entire install process yet) but was hoping someone might have an idea..

All, I have built and installed nut from git on Archlinux. It uses the usbhid driver. Beginning a couple of years ago, nut begin failing to run on Archlinux without 'tweaking' or 'fudging' the install. There are two primary problems: (1) upsdrvctl cannot be launched normally i.e. (/usr/sbin/upsdrvctl start) without failing to connect: Dec 14 02:24:39 phoinix systemd[1]:

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

Hello again. After an hour of Googling and just not "getting" it, I figured I'd call upon the list once more... I am starting upsd, upsmon, etc in my FreeBSD's /etc/rc.local, because it's easy. BUT... rc.shutdown seems kill off all those processes prior to excuting my upsdrvctl shutdown command, thereby preventing any ups communications and yup, the power don't get