[Nut-upsuser] Confusing Generic USB UPS cannot be matched

[R. G. Newbury]

On 12/01/2011 05:31 PM, Arnaud Quette wrote:
> 2011/12/1 R. G. Newbury<newbury at mandamus.org>:
>> On 11/30/2011 04:08 AM, Arnaud Quette wrote:

<snip>
>
> it's always a bad idea to not copy the list!

Well one of my pet peeves is seeing messages on the list which 
redundantly repeat again the entire redundantly repeated prior message, 
to merely add a couple of lines of response.

And my response contained masses of generally useless-to-anyone-else 
data, which you wished to see, I presume to parse for any errors I might 
have made..


>> ATTR{idVendor}=="0001", ATTR{idProduct}=="0000", MODE="664",
>> GROUP="@RUN_AS_GROUP@"
>
> if this is the actual file on your system
> ({/etc,/lib}/udev/rules/...), @RUN_AS_GROUP@ MUST be replaced by the
> actual value of the nut group.
> for you "nutty"

Hah! I see you did what I do: namely, respond before reading to the end 
of the message...Fixed later, as you noted there.

>> ***************************
>> /etc/ups/upsmon.conf
>> RUN_AS_USER nutty at localhost
>> MONITOR nexxtech at localhost 1 nutty at localhost  ***pass master
>
> the user should be 'nutty' without hostname, ie:
> MONITOR nexxtech at localhost 1 nutty  ***pass master
>
>> # USER  nutty and GROUP  nutty are valid users on the system
>
> don't be fooled by system Vs NUT users.
> the ones in upsmon.conf are references to upsd.users.
> the same goes for upsrw and upscmd

Unfortinately I have tried this both with and without the hostname and 
it makes no difference. There were about 5 reboot tries not recounted.

I created system user accounts in order to avoid permission problems 
(and selinux is disabled!)
<SNIP>
>> Dec  1 10:54:15 tor2 upsmon[2106]: Startup successful
>> Dec  1 10:54:15 tor2 upsd[2103]: User nutty at 127.0.0.1 logged into UPS
>> [nexxtech]
<SNIP>
> seems my udev rules remark is void...

Yes I corrected the GROUP entry.

>> ATTR{idVendor}=="0001", ATTR{idProduct}=="0000", MODE="664", GROUP="nutty"
>
> confirmed and fixed

>> [   13.505774] generic-usb 0003:0001:0000.0003: hiddev97,hidraw2: USB HID
>> v1.00 Device [MEC MEC0002] on usb-0000:00:06.0-4/input0
>> [   44.492226] usb 4-4: usbfs: USBDEVFS_CONTROL failed cmd blazer_usb rqt
>> 128 rq 6 len 255 ret -110
>> [   45.494192] usb 4-4: usbfs: USBDEVFS_CONTROL failed cmd blazer_usb rqt
>> 128 rq 6 len 255 ret -110

>> And I am where I was.......Except we can see the usbfs error
>> USBDEVFS_CONTROL .....
>
> it happens from time to time, no harm.

It may be 'no harm' but it is clearly 'no cure'....

Where can we go from here? I presume that this error message is actually 
output from 'usbfs', and it is unclear how that is triggered.


Geoff