RE: 20050225: Products not being decoded

"ldd decoders/dcmetr" as user ldm did the trick.  I guess since I last ran
the ldm I changed GEMPAK versions, and the new version uses the
~gempak/NAWIPS link to point to the working GEMPAK version directory.  I had
hard coded the LD_LIBRARY_PATH variable in my ldm .cshrc to the GEMPAK5.6
directory, and once 5.7.4 was running, whacked the old version to save disk
space, so it wasn't finding the libraries.  Now it is.

Thanks again!

Patrick

-----Original Message-----
From: Unidata Support [mailto:address@hidden]
Sent: Monday, February 28, 2005 12:03 PM
To: Patrick O'Reilly
Cc: address@hidden; address@hidden
Subject: 20050225: Products not being decoded



Patrick,

If the problem is "all" of the decoders, then it definitely
sounds like a configuration issue.

Assuming that the executables are the correct architecture....
have you tried firing one up from the command line?
If you have changed your OS since last run, its possible that
you are having a shared library issue. Linux seems to
keep messing with libg2c.so, and FC3 was missing it in an
early installation we did. The command "ldd $GEMEXE/dcmetr"
will show all the libraries and report if any are missing.

How about your ~ldm/data directory. Is this a symbolic link?

Since both the logs and the decoded file configuration are
relative directories, the ~ldm/data/gempak directory
could be the culprit if the data/ directory is a link
to another location that isn't correct.

The decoders will just append to log files, so corruption isn't
something that will hit the decoder. If the data file were corrupted
(or zero length), then the decoder would bomb...but you
would see log messages about that, so it seems like something
even higher up.

Are you using the new 6.2 LDM? If so, is your LDMHOME variable set?

Steve Chiswell
Unidata User Support


>From: "Patrick O'Reilly" <address@hidden>
>Organization: UCAR/Unidata
>Keywords: 200502251723.j1PHNrv2005119

>Hi gang,
>
>I restarted my ldm on a backup machine as my main one is having issues, and
>the data is being ingested fine.  Nothing that needs decoding is being
>decoded though, as the ldmd.log is FULL of:
>
>Feb 25 17:12:42 blizzard pqact[22915]: pipe_dbufput:
>decoders/dcmetr-b9-m72-ssfmetar_sa.tbl-ddata/gempak/logs/dcmetr.log-eGEMTBL
=
>/export/home/gempak/NAWIPS/gempak/tablesdata/gempak/surface/YYYYMMDD_sao.ge
m
>write error
>Feb 25 17:12:42 blizzard pqact[22915]: child 3376 terminated by signal 9
>Feb 25 17:12:42 blizzard pqact[22915]: child 3375 terminated by signal 9
>Feb 25 17:12:42 blizzard pqact[22915]: pbuf_flush (33) write: Broken pipe
>Feb 25 17:12:42 blizzard pqact[22915]: pipe_dbufput:
>decoders/dcmetr-b9-m72-ssfmetar_sa.tbl-ddata/gempak/logs/dcmetr.log-eGEMTBL
=
>/export/home/gempak/NAWIPS/gempak/tablesdata/gempak/surface/YYYYMMDD_sao.ge
m
>write error
>Feb 25 17:12:42 blizzard pqact[22915]: pipe_prodput: trying again
>Feb 25 17:12:42 blizzard pqact[22915]: pbuf_flush (33) write: Broken pipe
>Feb 25 17:12:42 blizzard pqact[22915]: pipe_dbufput:
>decoders/dcmetr-b9-m72-ssfmetar_sa.tbl-ddata/gempak/logs/dcmetr.log-eGEMTBL
=
>/export/home/gempak/NAWIPS/gempak/tablesdata/gempak/surface/YYYYMMDD_sao.ge
m
>write error
>
>I have checked everything (I think).  The main symptom (other than no data)
>seems to be that the logs aren't being written in ~ldm/data/gempak/logs for
>some reason.  I have tried removing the old logs and creating new empty
ones
>( e.g. "touch dcmetr.log") and then just removing the logs outright in case
>they're corrupt.  LDM owns the directory in question
(~ldm/data/gempak/logs)
>and it's permissions are 755.  The hard drive is far from full.  The
>permissions on the $GEMTBL directory:
>
>[ldm@blizzard]#ll /export/home/gempak/NAWIPS/gempak/
>drwxr-xr-x  27 gempak   staff        512 Nov 22 12:59 tables
>
>in fact all the ~gempak directories are 755 permissions and the ldm and
>gempak users are both in the same group, so everything should be readable
by
>ldm.  It is, I can navigate throughout the gempak installation as user ldm.
>I copied the decoders from $GEMEXE/bin to ~ldm/decoders today to make sure
>and they're all executable.
>
>I can't think of much else to do, other than give up.  Any clues?
>
>Patrick
>
--
****************************************************************************
<
Unidata User Support                                    UCAR Unidata Program
<
(303)497-8643                                                  P.O. Box 3000
<
address@hidden                                   Boulder, CO 80307
<
----------------------------------------------------------------------------
<
Unidata WWW Service              http://my.unidata.ucar.edu/content/support
<
----------------------------------------------------------------------------
<
NOTE: All email exchanges with Unidata User Support are recorded in the
Unidata inquiry tracking system and then made publicly available
through the web.  If you do not want to have your interactions made
available in this way, you must let us know in each email you send to us.