[Nut-upsdev] CENTOS 6.6 NUT RPM BUILD ISSUES

[Arnaud Quette]

Hey

2015-04-09 1:46 GMT+02:00 Charles Lepple <clepple at gmail.com>:

> On Apr 8, 2015, at 2:04 PM, Eric Cobb <Eric_Cobb at tripplite.com> wrote:
>
> Charles and list,
>
> If I leave the driver alone it does not eventually start.  It continues to
> report that it is unable to connect.  I have to perform a upsdrvctl stop ;
> upsdrvctl start (I actually just perform a init stop and start so that upsd
> and upsmon both restart) for the driver to actually connect to the ups.
>
> I have attached an strace of the upsdrvctl start command when it is ran at
> boot time via the init script. I'll let the experts make their assessment
> of what is going wrong.
>
> Here is the exact line out of the /etc/init.d/ups that i ran (I added -D
> and -u nut on the latest runs, I get the same issue with or without it) Let
> me know if you would like any further symptoms or output.
>
>
> start() {
>         echo -n $"Starting UPS Driver:"
>         echo "UPS DRIVER START" > /var/log/upslog
>         strace -f -o /var/log/nut/strace.log /usr/sbin/upsdrvctl -D -u nut
> start >> /var/log/upslog 2>&1 && success || failure
>         RETVAL=$?
>         Echo
>
> Eric Cobb
> ekcobb at tripplite.com
>
>
> The mailing list doesn't accept large attachments, so I attached a gzip'd
> copy of the log in case anyone else wants to take a look.
>
> It doesn't show timing information, or the content of the URBs, so it is
> hard to tell what the driver is trying to do at any given point.
>
> I recognize that it is a slight change of the experiment to remove
> upsdrvctl, but could you please start the driver directly in the init
> script with -DDD (path should be in the output of '/usr/sbin/upsdrvctl
> -D'), and redirect that output to a log file? (We had a reason for why
> upsdrvctl does not pass '-D' flags through to the driver, but the reason
> escapes me at the moment.)
>

simply debugging the driver controller in itself, more than passing the
debug flags to the driver(s)
that said, this point keeps on getting back, on and on.
RFC: we should probably consider for upsdrvctl that -D... is passed to the
driver(s) and -d... for upsdrvctl specifics.
there is no big issue with breaking backward compat here, so if that suits
you all, we can go on implementing that...


>
> It would also be useful to have the output of dmesg (or at least the
> USB-related subset), in case it has additional information on why
> libusb_get_interrupt() is failing.
>

2nded, along with your comment that I don't see any difference between
drivers startup process at boot time or later on, WRT to the mentioned
context.
the only point I also see would be some noise (interferences) tied to other
processes looking at USB devices.

Beside from Charles requested test, I would advise you to try increasing
the USB_TIMEOUT value (in usb-common.h) to see if it's just an transient
lack of responsiveness due to some kind of race to access USB devices...

cheers
Arno
-- 
Eaton Data Center Automation - Opensource Leader
NUT (Network UPS Tools) Project Leader - http://www.networkupstools.org
Debian Developer - http://www.debian.org
Free Software Developer - http://arnaud.quette.fr
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20150409/e92a15c3/attachment.html>