[Nut-upsuser] Usbhip-ups going wild

Thu Aug 6 10:34:39 UTC 2009

2009/8/6 Antoine Gatineau <antoine.gatineau at alcatel-lucent.com>

>  Ok, you're right, it is indeed a permission issue.
>

this is a classic.

> I have to chown root:dialout and chmod 0660 the /proc/bus/usb/003/006...
>
> However this should have been done by udev rules. Here is the line for my
> device :
> #  various models  - usbhid-ups
> ATTR{idVendor}=="0463", ATTR{idProduct}=="ffff", MODE="664",
> GROUP="dialout"
>
>
> It works well if I use the option -u root. I prefer to use usermode instead
> of super user if possible.
>

running as root was just to test and validate the issue.
in no way you should use it in production!

you have to troobleshoot why the nut rule isn't applied:
- check the location (/etc/udev/rules.d) and the permissions of the files
(do the same as for others)
- restart udev
- optionaly use "udevadm monitor" before plugging your UPS' USB cord...

In case there is a infinite loop or any misbehavior in usbhid-ups (or any
> driver), will it make a difference to run it as "nut" user instead of root.
> I mean towards other applications?
>
> By the way I found this in the mailing list archive (from Charles Lepple) :
> "When I plug in the USB cable I get the following message in my system log:
>
> kernel: usbhid: probe of 2-1:1.0 failed with error -5
> actually, this part is normal. The device is blacklisted from the
> kernel usbhid driver so that it can be claimed in userspace by
> newhidups.
>
> Did you see any error messages from the driver or other NUT components?"
>

the above is not true since 2.6.26 (or 24 I don't recall exactly).
I've once blacklisted MGE units in the kernel because:
- the work we did with Vojtech and Paul on the kernel stack (usbhid ->
hiddev) was not stable. At that, I rewrote the usb driver (from the old
hidups, relying on the above kernel driver to newhidups now called
usbhid-ups).
- the blacklist entries never stopped from attaching from userland. but
simply from attaching the kernel land hiddev driver...

I even tried to use the old rules from nut-2.2.0 but it doesn't work.
> The only solution I see is to always use -u root. So I modified ups init
> script to call upsdrvctl with option "-u root". Don't forget do set
> UPSD_OPTIONS="-u root" in /etc/sysconfig/ups after installation.
>
> How do I send you the RPM for redistribution?
>

post a URL for the moment. but I doubt we'll use these. maybe some other
will find it useful though.

cheers,
Arnaud

>  ------------------------------
> *De :* Arnaud Quette [mailto:aquette.dev at gmail.com]
> *Envoyé :* mercredi 5 août 2009 16:42
>
> *À :* Antoine Gatineau
> *Cc :* nut-upsuser
> *Objet :* Re: [Nut-upsuser] Usbhip-ups going wild
>
>
>
> 2009/8/5 Antoine Gatineau <antoine.gatineau at alcatel-lucent.com>
>
>>  Well,
>>
>> I have unfortunately uplugged the usb cord. Now I am not able to start the
>> drivers again.
>> When I plug in the usb cord I get :
>> Aug  5 16:23:33 localhost kernel: usb 3-2: new low speed USB device using
>> address 6
>> Aug  5 16:23:34 localhost kernel: usbhid: probe of 3-2:1.0 failed with
>> error -5
>>
>> When I start the nut driver using upsdrvctl start, I get :
>> Aug  5 16:24:05 localhost upsdrvctl: Can't claim USB device [0463:ffff]:
>> could not detach kernel driver from interface 0: Operation not permitted
>> Aug  5 16:24:05 localhost upsdrvctl: Network UPS Tools - Generic HID
>> driver 0.34 (2.4.1)
>> Aug  5 16:24:05 localhost upsdrvctl: USB communication driver 0.31
>> Aug  5 16:24:05 localhost upsdrvctl: Network UPS Tools - UPS driver
>> controller 2.4.1
>> Aug  5 16:24:05 localhost upsdrvctl: Driver failed to start (exit
>> status=1)
>>
>> I gess there are some conflicts somewhere. What is really wierd is that I
>> get the same messages after reboot or reinstallation of the rpms.
>> Any idea?
>>
>
> check that your hotplug or udev file is installed correctly, and that the
> permissions on the USB device are correctly set (using the lsusb + ls -l
> /dev/bus/usb/XXX/YYY method)
>
> to first validate that it's a device perm issue, simply launch the driver
> as root, ie:
> $ /path/to/usbhid-ups -a <ups>
>
> this should start and happily says "Detected something..."
>
> cheers,
> Arnaud
> --
> Linux / Unix Expert R&D - Eaton - http://www.eaton.com/mgeops
> Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org/
> Debian Developer - http://www.debian.org
> Free Software Developer - http://arnaud.quette.free.fr/
>
>
>>  ------------------------------
>>  *De :* Arnaud Quette [mailto:aquette.dev at gmail.com]
>> *Envoyé :* mercredi 5 août 2009 11:16
>>
>> *À :* Antoine Gatineau
>> *Cc :* nut-upsuser
>> *Objet :* Re: [Nut-upsuser] Usbhip-ups going wild
>>
>>
>> 2009/8/4 Antoine Gatineau <antoine.gatineau at alcatel-lucent.com>
>>
>>>  Hello everyone,
>>>
>>
>> Hi Antoine,
>>
>>
>>>
>>> I have nut and nut-client installed from rpm, up and running without any
>>> error in the logs or at screen.
>>> upsc gives me the state of the battery and stuff. It seems functional.
>>>
>>
>> nice
>>
>>
>>>  Is there something to do in order to verify the health of the whole
>>> chain? (upsmon -> upsd -> upsdrv)
>>>
>>
>> yep, unplug the UPS' power cord, and check that upsc has an ups.status =
>> OB
>>
>>
>>
>>>  One last question, after installing the rpms, /var/state/ups is not
>>> created and the rights are not given like it should. I was suprised to see
>>> that this was not ntegrated in RHEL5 rpms... Is there some restriction to
>>> integrate that configuration?
>>>
>>
>> most modern distro have a volatile /var fs. For example, on Debian, the
>> init.d script create these dirs at launch time...
>>
>> cheers,
>> Arnaud
>> --
>> Linux / Unix Expert R&D - Eaton - http://www.eaton.com/mgeops
>> Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org/
>> Debian Developer - http://www.debian.org
>> Free Software Developer - http://arnaud.quette.free.fr/
>>
>>
>>>  ------------------------------
>>>  *De :* Arnaud Quette [mailto:aquette.dev at gmail.com]
>>> *Envoyé :* lundi 3 août 2009 21:46
>>> *À :* Antoine Gatineau
>>> *Cc :* nut-upsuser
>>> *Objet :* Re: [Nut-upsuser] Usbhip-ups going wild
>>>
>>>
>>>
>>> 2009/8/3 Antoine Gatineau <antoine.gatineau at alcatel-lucent.com>
>>>
>>>>  I tried to recompile without xorg-x11-devel and I get this error :
>>>> configure: error: libgd not found, required for CGI build.
>>>> It is indeed required for nut-cgi
>>>> udev-devel, however, is not required.
>>>>
>>>>
>>>
>>> yup, you got me wrong: only the dbus-glib as to be removed. xorg-devel
>>> (or xpm-devel) is needed for nut-cgi
>>>
>>>
>>>>  Anyway I made it build correctly.
>>>> I attached nut.spec (modified for RHEL4) and nut.spec.ori (original spec
>>>> file for RHEL5) for info.
>>>>
>>>> There were no %files entry for libhidups, libhid.usermap
>>>>
>>>
>>> these 2 are for hotplug. if you use udev, you don't need these.
>>>
>>>
>>>>  and 20-ups-nut-device.fdi
>>>>
>>>
>>> this file is for HAL. so not needed too.
>>>
>>>
>>>>  in the original spec file, so I added them. I'm not an rpm building
>>>> expert but I wonder how it could work...
>>>> I also removed hal, powerman and netxml-ups man page and related files
>>>> as they are not used in this package.
>>>>
>>>> I didn't test it running yet but I expect it to be OK. I'll come back to
>>>> you with results.
>>>>
>>>> BTW, in the first answer to this (too?) long thread, Arjen said that
>>>> there were lot of bug fixes and performance improvement done since
>>>> nut-2.2.0. Is there a bug tracker to seek if my issues will be solved with
>>>> this new one?
>>>>
>>>
>>> to be short: ChangeLog
>>>
>>> cheers
>>> Arnaud
>>> --
>>> Linux / Unix Expert R&D - Eaton - http://www.eaton.com/mgeops
>>> Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org/
>>> Debian Developer - http://www.debian.org
>>> Free Software Developer - http://arnaud.quette.free.fr/
>>>
>>>
>>
>>
>>
>>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20090806/de5a755c/attachment-0001.htm>