Hi Charles, Thank you for sticking with me through this! Well, whaddya know, when run with -DDDDD it works! upsc consistently returns data. Maybe it's a timing thing, or a select affected by I/O or something tricky like that. Nonetheless, I ran it, hit upsc eaton multiple times, collected the output and attached it. If this doesn't give you what you need, I can retry with fewer/more D's or whatever you like. I see upstart and systemd. # ps aux | egrep '[s]ystemd|[u]pstart' root 527 0.0 0.0 18208 1740 ? S May03 0:00 upstart-udev-bridge --daemon root 567 0.0 0.0 36784 1904 ? Ss May03 0:00 /lib/systemd/systemd-udevd --daemon root 582 0.0 0.0 15404 740 ? S May03 0:00 upstart-file-bridge --daemon root 614 0.0 0.0 30724 1648 ? Ss May03 0:00 /lib/systemd/systemd-logind root 867 0.0 0.0 15260 648 ? S May03 0:00 upstart-socket-bridge --daemon Apparmor is present, but disabled due to another application's requirements: # apparmor_status apparmor module is loaded. 0 profiles are loaded. 0 profiles are in enforce mode. 0 profiles are in complain mode. 0 processes have profiles defined. 0 processes are in enforce mode. 0 processes are in complain mode. 0 processes are unconfined but have a profile defined. I couldn't find any crashes in dmesg, just this over and over: [167914.284728] usb 6-1: USB disconnect, device number 21 [167915.292292] usb 6-1: new low-speed USB device number 22 using uhci_hcd [167916.162823] usb 6-1: New USB device found, idVendor=0463, idProduct=ffff [167916.162827] usb 6-1: New USB device strings: Mfr=1, Product=2, SerialNumber=4 [167916.162829] usb 6-1: Product: Ellipse PRO [167916.162831] usb 6-1: Manufacturer: EATON [167916.162833] usb 6-1: SerialNumber: G343F52229 [167919.940287] hid-generic 0003:0463:FFFF.0015: hiddev0,hidraw0: USB HID v1.10 Device [EATON Ellipse PRO] on usb-0000:00:1d.0-1/input0 Thank you, Ken On Wed, May 4, 2016 at 11:00 PM, Charles Lepple <clepple at gmail.com> wrote:> On May 4, 2016, at 10:01 AM, Ken Marsh <ken.marsh at sparkpost.com> wrote: > > > > Is this actually functional? Usually I don't consider NUT operational > until upsc works (among other things). > > You're right, the "ups.status: WAIT" isn't fully functional. I am > surprised, though, since the usual problem area is driver-to-hardware > rather than upsd-to-driver. > > From the state where everything has been started, what if you kill the > driver, and restart it from the command line with five "-D" flags? I'm > looking for a line like this: "0.008735 dstate_init: sock > /var/tmp/macosx-ups-osx open on fd 3" (although it potentially might happen > several times in your case). Please check upsc as well, and after a few > cycles between the two messages, you can kill the driver and zip up the log. > > A few more background things (since I guess I skipped the non-LTS versions > between Ubuntu 12.04 and 14.04): which init system does this version run? > Do you know if there are any apparmor profiles that might be preventing the > driver and upsd from talking? Any crash messages in dmesg? > > -- > Charles Lepple > clepple at gmail > > > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20160505/dddb3ef8/attachment-0001.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: output.txt.gz Type: application/x-gzip Size: 31526 bytes Desc: not available URL: <http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20160505/dddb3ef8/attachment-0001.bin>
On May 5, 2016, at 9:25 AM, Ken Marsh <ken.marsh at sparkpost.com> wrote:> > Well, whaddya know, when run with -DDDDD it works! upsc consistently returns data. Maybe it's a timing thing, or a select affected by I/O or something tricky like that. Nonetheless, I ran it, hit upsc eaton multiple times, collected the output and attached it. If this doesn't give you what you need, I can retry with fewer/more D's or whatever you like.Probably is timing, then. See below.> I couldn't find any crashes in dmesg, just this over and over: > > [167914.284728] usb 6-1: USB disconnect, device number 21 > [167915.292292] usb 6-1: new low-speed USB device number 22 using uhci_hcdThis part isn't good. While the usbhid-ups can attempt to recover from this, it means that for a second at a time (those times in brackets are seconds since boot), the UPS is logically disconnected from the USB bus. (This is what happens if you have a phone with a worn-out USB connector, and it beeps if you wiggle the plug.) After it reconnects, due to the low bit-rate of low-speed USB, it takes 5-10 seconds for the driver to reconnect. Some people have reported success with higher-quality USB cables (2.0 rated, even though the UPS will never use the faster modes). Others have moved the cable to a non-3.0 port. A hub might also clean up the signal, but then you need to make sure the hub power supply is on battery as well. You should only see the "new low-speed USB device" message once for the UPS, when it is first plugged in (or when the system is booted). -- Charles Lepple clepple at gmail
Hmm. Next week I'll experiment with different cables, and see if I can find a hub. These results are the same on two different hosts, two different 5S 1000LCD UPS's, each with their own OEM cable, which is a bit thicker and more substantial looking than the ones that came with the Eaton 5110 aka Powerware 1000i. So while both cables may be bad, it's starting to look like this model UPS may have a flawed USB design?! -Ken On Thu, May 5, 2016 at 10:22 PM, Charles Lepple <clepple at gmail.com> wrote:> On May 5, 2016, at 9:25 AM, Ken Marsh <ken.marsh at sparkpost.com> wrote: > > > > Well, whaddya know, when run with -DDDDD it works! upsc consistently > returns data. Maybe it's a timing thing, or a select affected by I/O or > something tricky like that. Nonetheless, I ran it, hit upsc eaton multiple > times, collected the output and attached it. If this doesn't give you what > you need, I can retry with fewer/more D's or whatever you like. > > Probably is timing, then. See below. > > > I couldn't find any crashes in dmesg, just this over and over: > > > > [167914.284728] usb 6-1: USB disconnect, device number 21 > > [167915.292292] usb 6-1: new low-speed USB device number 22 using > uhci_hcd > > This part isn't good. While the usbhid-ups can attempt to recover from > this, it means that for a second at a time (those times in brackets are > seconds since boot), the UPS is logically disconnected from the USB bus. > (This is what happens if you have a phone with a worn-out USB connector, > and it beeps if you wiggle the plug.) After it reconnects, due to the low > bit-rate of low-speed USB, it takes 5-10 seconds for the driver to > reconnect. > > Some people have reported success with higher-quality USB cables (2.0 > rated, even though the UPS will never use the faster modes). Others have > moved the cable to a non-3.0 port. A hub might also clean up the signal, > but then you need to make sure the hub power supply is on battery as well. > > You should only see the "new low-speed USB device" message once for the > UPS, when it is first plugged in (or when the system is booted). > > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20160506/89ba6506/attachment.html>