similar to: "upsdrvctl shutdown" ignores "-u"

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

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

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

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

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

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 09:04 PM, Charles Lepple wrote: >> Is there someway nut can be modified to probe the 0664 permission usb >> devices >>> and then connect as root before dropping permissions back to the "nut" >>> gid? > Given that the udev method should still work (and seems to, for handcrafted > udev rules files), I would like to run that to ground first.

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

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

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

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"

On Dec 15, 2013, at 2:03 PM, David C. Rankin wrote: > On 12/14/2013 09:04 PM, Charles Lepple wrote: >>> Is there someway nut can be modified to probe the 0664 permission usb >>> devices >>>> and then connect as root before dropping permissions back to the "nut" >>>> gid? >> Given that the udev method should still work (and seems to, for

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

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..

hi i have a belkin ups here some setting chmod 0600 /dev/hiddev0 chown nut:root /dev/hiddev0 linux:/home/sonia # /usr/lib/ups/driver/upsdrvctl start Network UPS Tools - UPS driver controller 2.0.4 Network UPS Tools: New USB/HID UPS driver 0.28 (2.0.4) No matching USB/HID UPS found Driver failed to start (exit status=1) linux:/home/sonia # /usr/lib/ups/driver/upsdrvctl -u root start