similar to: Startup Scripts for upsdrvctl and upsd

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

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

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

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

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

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 >

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

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

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

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

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/16/2013 09:23 PM, Charles Lepple wrote: > Not sure - I didn't write the getaddrinfo() code in upsd, but it seemed to > follow all of the recommendations on how to use that function. So if there is > a way to fix it in the NUT code, I am not aware of it (and would appreciate > any updates if that turns out to be the case). > > The odd part is that it looks like you went

OK, so I made this file: ------------------------------------------ #!/bin/sh<\n> #chkconfig: 2345 60 99 #description: NUT ups daemon if [ ! -f /usr/local/ups/bin/upsd ] then echo "NUT startup: cannot start" exit fi case "$1" in "start") chmod 0600 /proc/bus/usb/005/002 chown nut:nut /proc/bus/usb/005/002 /usr/local/ups/bin/upsdrvctl

On Dec 16, 2013, at 10:11 PM, David C. Rankin wrote: > On 12/16/2013 08:01 PM, Charles Lepple wrote: >> On Dec 16, 2013, at 4:19 PM, David C. Rankin wrote: >> >>>> Dec 16 14:05:16 phoinix upsd[369]: getaddrinfo: Servname not supported for >>>> ai_socktype >> [...] >>>> The kernel update was from linux (3.12.1-3 -> 3.12.5-1), I don't

Hello all, I'm new to nut, i've donwloaded and installed without problem apparently nut 2.0.3 on a slackware 10.x (1 i think). /usr/local/ups/bin/upsdrvctl start seems to work correctly. but when i do: /usr/local/ups/sbin/upsd i've got: Network UPS Tools upsd 2.0.3 stat /usr/local/ups/etc/upsd.conf: Permission denied but upsd.conf is 0640 and set with root.ups as stated in some

I haven't been able to use my ups since upgrading to Fedora 7. The problem seems to be that when upsd is started, it doesn't create a pid file and produces the error message fopen /var/run/nut/upsd.pid: No such file or directory But I have # ls -ld /var/run/nut 8 drwxrwx--- 2 nut nut 4096 2007-08-16 16:26 /var/run/nut/ The call to upsd is /usr/sbin/upsd -DD -u nut -c reload

Hi, When I start upsd under normal conditions, I get this: -------------------------------------------------------------------------------- Network UPS Tools upsd 2.0.4 /etc/nut/upsd.conf is world readable Can't connect to UPS [tripplite] (tripplite_usb-auto): No such file or directory /etc/nut/upsd.users is world readable Synchronizing........ giving up

On 12/16/2013 08:01 PM, Charles Lepple wrote: > On Dec 16, 2013, at 4:19 PM, David C. Rankin wrote: > >> > Dec 16 14:05:16 phoinix upsd[369]: getaddrinfo: Servname not supported for >> > ai_socktype > [...] >> > The kernel update was from linux (3.12.1-3 -> 3.12.5-1), I don't see what >> > could have changed. How do I attempt to further