That worked out just fine. What I am currently running into are conditions where I am getting the following error that I figured I would share. Error: libusb_get_interrupt() returned 0 instead of 8 while sending 3a 4d b2 0d 00 00 00 00 '.M......' Conditions: upsdrvctl start via Init Script at Boottime. If I run the init script after boot, I do not receive this error. Eric Cobb ekcobb at tripplite.com From: Charles Lepple [mailto:clepple at gmail.com] Sent: Thursday, March 26, 2015 8:59 PM To: Eric Cobb Cc: nut-upsdev at lists.alioth.debian.org Subject: Re: CENTOS 6.6 NUT RPM BUILD ISSUES On Mar 26, 2015, at 11:16 AM, Eric Cobb <Eric_Cobb at tripplite.com<mailto:Eric_Cobb at tripplite.com>> wrote: The init script no longer works so a new script needs to be written to enable and disable the ups functionality, however it is communicating with the UPS properly. The question I have at this point is, is there a way I can set this so that once Line Power is disrupted it starts the shutdown command on the system versus waiting for the UPS battery to be "critical"? I would probably just raise the low battery threshold, but to trigger the shutdown immediately, you could write a NOTIFYCMD script for upsmon that looks for the ONBATT event (corresponds to "OB" for ups.status): http://www.networkupstools.org/docs/man/upsmon.html http://www.networkupstools.org/docs/man/upsmon.conf.html -- Charles Lepple clepple at gmail ________________________________ 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/20150406/0fe5bd63/attachment.html>
On Apr 6, 2015, at 1:58 PM, Eric Cobb <Eric_Cobb at tripplite.com> wrote:> That worked out just fine. What I am currently running into are conditions where I am getting the following error that I figured I would share. > > Error: > libusb_get_interrupt() returned 0 instead of 8 while sending 3a 4d b2 0d 00 00 00 00 '.M......' > > > Conditions: upsdrvctl start via Init Script at Boottime. If I run the init script after boot, I do not receive this error.That is odd. Running the init script later should pass the same parameters to the driver. The only thing I can think of: other processes are interfering at boot time? Does the driver eventually start, or does that error continue? -- Charles Lepple clepple at gmail -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20150406/619bef33/attachment.html>
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.) 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. -- Charles Lepple clepple at gmail -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20150408/0f483732/attachment-0002.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: tripplite_3005_CentOS_6.6_strace.log.gz Type: application/x-gzip Size: 5172 bytes Desc: not available URL: <http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20150408/0f483732/attachment-0001.bin> -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20150408/0f483732/attachment-0003.html>
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>