[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[LDM #PHT-262834]: ldm-6.9.4 error

This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.

  • Subject: [LDM #PHT-262834]: ldm-6.9.4 error
  • Date: Mon, 24 Jan 2011 15:44:27 -0700
Terri,

> I've installed the newest version of the ldm (6.9.4) on two Debian
> linux machines:
> 
> Linux traffic 2.6.26-2-amd64 #1 SMP Thu Nov 25 04:30:55 UTC 2010 x86_64 
> GNU/Linux
> - Debian version 5.0.7
> - getts data from upstream RAL servers fine (version 6.8.1)
> 
> Linux tail 2.6.26-2-amd64 #1 SMP Thu Nov 25 04:30:55 UTC 2010 x86_64 GNU/Linux
> - Debian version 5.0.7
> - should be downstream from traffic for same data
> 
> Another host running an older ldm version (6.8.1) is getting data from
> traffic fine as well.
> 
> The problem is that the ldm will not start on tail.  It exits
> gracefully, but no daemons are running.  I found this in the syslog
> file:
> 
> Jan 22 00:15:41 tail traffic.rap.ucar.edu[32719] ERROR: assertion 
> "pIf(xdrs->x_op == XDR_ENCODE, *cpp != NULL && **cpp != 0)" failed: file 
> "ldm_xdr.c", line 19
> 
> But nothing else that seemed relevant.  I've attached the ldmd.conf
> files from both machines that were put together by the project
> engineers.  Is there something we are missing with the new version?

Wow! That's bizarre (in the same way that a tsunami is moist)!

I didn't think the LDM configuration-files would be all that useful, but then I 
noticed that both EXEC pqbinstats(1). That's a really old program and has be 
replaced by rtstats(1). Do you really use the output of pqbinstats(1)?

Also (and this might be the cause of your problem) the LDM configuration-file 
for Tail has two REQUEST entries for FNEXRAD data that have the empty string 
("") as the pattern specification rather than the recommended universal regular 
expression, ".*". Let me know if changing the pattern fixes the problem. If it 
does, then I'll make a new release that emits a more useful error message.

> Thanks,
> --
> Terri Eads            Systems Administrator
> address@hidden                Research Applications Laboratory
> 303-497-8425          National Center for Atmospheric Research

Regards,
Steve Emmerson

Ticket Details
===================
Ticket ID: PHT-262834
Department: Support LDM
Priority: Normal
Status: Closed