20010209: gempak decoders in gempak.56a

Ruth,

Do you have any dc log file output from these decoders in data/gempak/logs?

If you don't have any decode logs, then you might check to make sure that 
the decoders themselves are viewable and executable by the ldm (just incase 
the umask was set when they were installed) as well as the paths to
the  /ljuka/gemadm/gempak/bin/sol directory. 

The otherthing to check is to make sure that the ldm process can invoke
the programs, try typing "ldd  /ljuka/gemadm/gempak/bin/sol/dcgrib2" for
example from the ldm account. Its possible that the decoder is looking for 
runtime shared libraries (like /opt/SUNWspro/lib/....) and not finding them.
The ldd command will show you what libraries are trying to be resolved, and 
if any aren't being found.

Steve Chiswell



>From: Ruth Platner <address@hidden>
>Organization: UCAR/Unidata
>Keywords: 200102091618.f19GIhL01549

>Hi,
>
>I'm having trouble with the new ldm decoders that are part of gempak
>version 56a. The NWX entries in pqact.conf are fine, but all of the
>gempak decoder entries are failing. I've now turned off all gempak
>decoders except for the following two pqact.conf entries:
>
>HRS     ^H.[I-P]... KWB. ([0-3][0-9])([0-2][0-9]).*
>        PIPE    /ljuka/gemadm/gempak/bin/sol/dcgrib2 -d
>data/gempak/logs/dcgrib.log
>                -e GEMTBL=/ljuka/gemadm/gempak/gempak/tables
>                data/gempak/hds/YYYYMMDDHH_thin.gem
>
>
>
>DDS|IDS ^S[AP].* .... ([0-3][0-9])([0-2][0-9])
>        PIPE    /ljuka/gemadm/gempak/bin/sol/dcmetr -b 9 -m 72 -s
>sfmetar_sa.tbl
>        -d data/gempak/logs/dcmetr.log
>        -e GEMTBL=/ljuka/gemadm/gempak/gempak/tables
>        data/gempak/surface/YYYYMMDD_sao.gem
>
>Here's some of the errors from the log file
>Feb 09 15:51:14 aspre pqact[4561]: pbuf_flush (4) write: Broken pipe
>Feb 09 15:51:14 aspre pqact[4561]: pipe_dbufput:
>/ljuka/gemadm/gempak/bin/sol/d
>cgrib2-ddata/gempak/logs/dcgrib.log-eGEMTBL=/ljuka/g
>Feb 09 15:51:14 aspre pqact[4561]: pipe_prodput: trying again
>Feb 09 15:51:14 aspre pqact[4561]: child 23835 terminated by signal 9
>
>Feb 09 15:37:34 aspre pqact[4561]: pbuf_flush (4) write: Broken pipe
>Feb 09 15:37:34 aspre pqact[4561]: pipe_dbufput:
>/ljuka/gemadm/gempak/bin/sol/dc
>metr-b9-m72-ssfmetar_sa.tbl-ddata/gempak/logs/dcmetr
>Feb 09 15:37:34 aspre pqact[4561]: pipe_prodput: trying again
>Feb 09 15:37:34 aspre pqact[4561]: child 22425 terminated by signal 9
>
>These data directories exist and have the same ownership as ldm. There
>are no existing files in the hds or surface directories either.
>
>aspre gempak 704% ls -al
>total 30
>drwxr-xr-x  13 ldm      staff        512 Feb  2 10:56 .
>drwxr-xr-x   8 ldm      staff        512 Jan 31 01:07 ..
>drwxr-xr-x   2 ldm      staff        512 Sep  1 13:56 acars
>drwxr-xr-x   2 ldm      staff       2560 Jan 31 18:00 hds
>drwxr-xr-x   2 ldm      staff        512 Jan 30 17:59 logs
>drwxr-xr-x   2 ldm      staff        512 Feb  2 10:56 model
>drwxr-xr-x   2 ldm      staff        512 Jan 31 18:00 mos
>drwxr-xr-x   2 ldm      staff        512 Sep  7  1999 nldn
>drwxr-xr-x  17 ldm      staff        512 Jan 30 19:26 nwx
>drwxr-xr-x   2 ldm      staff        512 Sep  1 13:56 profiler
>drwxr-xr-x   6 ldm      staff        512 Sep  1 13:55 storm
>drwxr-xr-x   2 ldm      staff       1024 Feb  7 18:00 surface
>drwxr-xr-x   2 ldm      staff        512 Feb  5 18:00 upperair
>aspre gempak 705% pwd
>/home/ldm/data/gempak
>
>aspre gempak 706% /usr/ucb/ps -auxww | grep ldm
>ldm       4561  0.9 10.310203225464 ?        S 02:00:05  3:38 pqact
>ldm      22521  0.6  0.8 2576 1824 ?        S 10:38:06  0:34
>/usr/local/ldm/decoders/bin/gribtonc -q lin
>decoders/etc/part.avn-1.25x1.25.cdl
>data/GRIB/2001020912_avn-1.25x1.25.nc
>ldm       4560  0.3 10.110136824888 ?        S 02:00:05  1:25 pqbinstats
>
>ldm       4562  0.3 12.010149629624 ?        S 02:00:05  1:36 rpc.ldmd
>-q /usr/local/ldm/data/ldm.pq /usr/local/ldm/etc/ldmd.conf
>
>I'm running ldm-5.1.2 on a Sparc Ultra 10 with SunOS 5.7.
>
>The usual reason for those signal 9 errors is nonexistent data
>directories or ownership problems with the data directories, but I don't
>see that here.
>
>Thanks for your help,
>
>Ruth
>