[Nut-upsuser] newhidups driver process crashed shortly after upsd loads

[Charles Lepple]

On 3/13/06, Steve Ziuchkovski <steve at ziuchkovski.com> wrote:
> I'm using an APC Back-UPS XS with nut 2.0.3. I've recompiled/reinstalled the
> source, and switched over to the newhidups driver (instead of the old hidups
> driver).
>
> I modified by ups.conf to use newhidups.

Sounds good so far.

> The hotplug files were not automatically installed, I had to copy those from
> the scripts directory to my hotplug/usb directory.

Which distribution? (Trying to work with every distribution's hotplug
systems is like herding cats, but hopefully we'll catch up before they
all start using some other hotplug system)

> The newhidups driver loads find and then works for a moment to a few
> minutes. I've had it working long enough a couple times to get upsd loaded
> and query it with upsc. However, it dies shortly after running with a
> segmentation fault. Here is a sample of the last bit of output from
> "/usr/local/ups/bin/newhidups -u nut -DDD /dev/hiddev0" (nothing about the
> process death is in syslog):

Monitoring process termination is complicated by potentially having
different UIDs for each component. However, upsd should have logged
something along the lines of "stale data" a little while after the
driver died.

> There are more lines of the unknown variable problem before it faults.

Now we're getting beyond my realm of expertise. Peter Selinger is
probably the one to ask about this, but he's on vacation at the
moment.

Maybe we can do some triage, though. After running newhidups once (but
before unplugging the USB cable), can you run 'lsusb -vvv' as root,
and trim the output to just show your UPS? (This could be something
like 'lsusb -vvv -d 51d:' - trailing colon is important - but
sometimes that doesn't work.) It's probably best to redirect it to a
file, then gzip before attaching - the report descriptors can get
long. This will give us an idea of what variables your UPS can report.
It is possible that newhidups is expecting your UPS to provide a
certain variable, but it is being presented somewhere else.

Another thing to try is to run the program under gdb, or enable core
dumps ('ulimit -c 10M' or something) and then run gdb on both the
executable and the core file after it dies. If you type 'bt' at the
gdb prompt, you should get a list of functions on the call stack when
the driver terminated.

Sorry for the delay in getting back to you - still catching up from
being on the road for a while.

--
- Charles Lepple