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 <[email protected]> wrote: > On May 4, 2016, at 10:01 AM, Ken Marsh <[email protected]> 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@gmail > > > >
output.txt.gz
Description: GNU Zip compressed data
_______________________________________________ Nut-upsuser mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
