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 <clep...@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 <lanerussell...@gmail.com> > wrote: > > Do you need any more info from me on this? > > On Fri, Oct 14, 2016 at 7:56 AM, Lane Russell <lanerussell...@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 <clep...@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. >> >> >> >
_______________________________________________ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser