Nut upsuser - Mar 2006 - newhidups driver process crashed shortly after upsd loads

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.

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

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):

================Object: UPS.PresentStatus.VoltageNotRegulated = 0
entering path_to_string()
Looking up 00840002
Looking up ff860080
Object: UPS.PresentStatus.ff860080 = 0
entering path_to_string()
Looking up 00840002
Object: UPS.PresentStatus. = 0
entering path_to_string()
Looking up 00840002
Object: UPS.PresentStatus. = 0
entering path_to_string()
Looking up 00840002
Object: UPS.PresentStatus. = 0

=>Got 16 HID Objects...
Object: UPS.PresentStatus. = 0
find_hid_info: unknown variable: UPS.PresentStatus.

Object: UPS.PresentStatus. = 0
find_hid_info: unknown variable: UPS.PresentStatus.

Object: UPS.PresentStatus. = 0
find_hid_info: unknown variable: UPS.PresentStatus.

Object: UPS.PresentStatus.ff860080 = 0
find_hid_info: unknown variable: UPS.PresentStatus.ff860080

Object: UPS.PresentStatus.VoltageNotRegulated = 0
find_hid_info: unknown variable: UPS.PresentStatus.VoltageNotRegulated
===================
There are more lines of the unknown variable problem before it faults.

Has anyone experienced this before? Please help me help you help me - can I 
provide any other logs or configuration information to describe my problem 
more clearly?

Steve Z.

On 3/13/06, Steve Ziuchkovski <steve@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