How could I check if another instance is causing me issues? This is a
running on a KVM host server, so there's very little activity on the server
itself.
On Sat, Oct 22, 2016 at 1:16 PM, Charles Lepple <clepple at gmail.com>
wrote:
> No, just a few extra hours in the day :)
>
> This is a tougher problem.
>
> In the mean time, can you make sure the "Got disconnected by another
> driver " is not really caused by an extra instance of the NUT driver?
> (Could be kernel or other user space activity)
>
> - Charles
>
> On Oct 21, 2016, at 11:37 AM, Lane Russell <lanerussell028 at
gmail.com>
> wrote:
>
> Do you need any more info from me on this?
>
> On Fri, Oct 14, 2016 at 7:56 AM, Lane Russell <lanerussell028 at
gmail.com>
> wrote:
>
>> ?Increasing 'pollinterval' to 5s did not seem to work. I've
attached the
>> relevant portions of the upsdrvctl debug. I believe the message
we're
>> looking at is:
>>
>> 9528.632309 libusb_get_report: error sending control message: Device or
>> resource busy
>> 9528.632318 Can't retrieve Report 16: Device or resource busy
>> 9528.632326 Got disconnected by another driver: Device or resource
busy?
>>
>> On Wed, Oct 12, 2016 at 8:35 AM, Charles Lepple <clepple at
gmail.com>
>> wrote:
>>
>>> On Oct 12, 2016, at 9:07 AM, Lane Russell wrote:
>>> >
>>> > Apologies, I did mean upsmon.conf. ups.conf
"pollinterval" is not
>>> called out, so I assume it's using the default of 2s.
"pollfreq" and
>>> "pollfreqalert" are both set to 10s in upsmon.conf at the
moment.
>>> "deadtime" is set to 30s.
>>>
>>> No problem, the names are a bit confusing.
>>>
>>> > I've attached the output of "sudo /lib/nut/usbhid-ups
-a ups -DDD".
>>>
>>> I forgot to mention, the list limits messages to ~40 KB, so for the
next
>>> time, please compress the log ("gzip -9" or similar).
>>>
>>> However, we would need the log at the point where the UPS
disconnects.
>>> (The beginning looks normal.) If the compressed log is still large,
let me
>>> know and we can trim out the interesting part.
>>>
>>> > Forgive me, but I've never rebuilt a driver, and I'm
not sure what the
>>> libusb branch is. Could you elaborate? Or perhaps this issue
won't be
>>> related to that and we won't have to go down that path.
>>>
>>> There are still a few things to try before then, and they are
somewhat
>>> related to what the log looks like at the point when the driver
declares
>>> the data stale.
>>>
>>> Also, maybe I can get things set up again to build packages for an
>>> Ubuntu PPA.
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20161024/9aab3840/attachment.html>