[Nut-upsuser] New UPS Support: Eaton 5S 1000

[Ken Marsh]

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>