[Nut-upsdev] CENTOS 6.6 NUT RPM BUILD ISSUES

[Eric Cobb]

Hello everyone,

Here are the output log files as requested.

Eric Cobb
ekcobb at tripplite.com

From: aquette.dev at gmail.com [mailto:aquette.dev at gmail.com] On Behalf Of Arnaud Quette
Sent: Thursday, April 09, 2015 5:03 AM
To: Charles Lepple
Cc: Eric Cobb; nut-upsdev at lists.alioth.debian.org
Subject: Re: [Nut-upsdev] CENTOS 6.6 NUT RPM BUILD ISSUES

Hey

2015-04-09 1:46 GMT+02:00 Charles Lepple <clepple at gmail.com<mailto:clepple at gmail.com>>:
On Apr 8, 2015, at 2:04 PM, Eric Cobb <Eric_Cobb at tripplite.com<mailto: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<mailto: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
________________________________
This message is for the addressee's use only. It may contain confidential information. If you receive this message in error, please delete it and notify the sender. Tripp Lite disclaims all warranties and liabilities, and assumes no responsibility for viruses which may infect an email sent to you from Tripp Lite and which damage your electronic systems or information. It is your responsibility to maintain virus detection systems to prevent damage to your electronic systems and information.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20150413/b7efccf3/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dmesg.rar
Type: application/octet-stream
Size: 12240 bytes
Desc: dmesg.rar
URL: <http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20150413/b7efccf3/attachment-0002.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tripplite.rar
Type: application/octet-stream
Size: 44789 bytes
Desc: tripplite.rar
URL: <http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20150413/b7efccf3/attachment-0003.obj>