[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
20010209: 20010209: gempak decoders in gempak.56a
- Subject: 20010209: 20010209: gempak decoders in gempak.56a
- Date: Fri, 09 Feb 2001 13:21:14 -0700
Ruth,
Apparently there is an incompatibility in the libraries.
I compiled the solaris binaries here using WS6, eg the
/opt/SUNWspro/lib/libsunmath.so.1 here is a link to:
../WS6/lib/libsunmath.so.1
Steve Chiswell
Unidata User Support
>From: Ruth Platner <address@hidden>
>Organization: UCAR/Unidata
>Keywords: 200102091853.f19IrlL08018
>Unidata Support wrote:
>
>> Ruth,
>>
>> Do you have any dc log file output from these decoders in data/gempak/logs?
>>
>
>No there is nothing being written to the log files.
>
>>
>> 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.
>
>These are executable
>-rwxr-xr-x 1 gemadm staff 328800 Dec 15 13:44 dcgrib2
>-rwxr-xr-x 1 gemadm staff 343472 Dec 15 13:42 dcmetr
>
>> 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.
>
>aspre ldm 69% ldd /ljuka/gemadm/gempak/bin/sol/dcgrib2
> libm.so.1 => /burga/bopt/SUNWspro/lib/libm.so.1
> libsocket.so.1 => /usr/lib/libsocket.so.1
> libnsl.so.1 => /usr/lib/libnsl.so.1
> libF77.so.4 => /burga/bopt/SUNWspro/lib/libF77.so.4
> libM77.so.2 => /burga/bopt/SUNWspro/lib/libM77.so.2
> libsunmath.so.1 => /burga/bopt/SUNWspro/lib/libsunmath.so.1
> libc.so.1 => /usr/lib/libc.so.1
> libdl.so.1 => /usr/lib/libdl.so.1
> libmp.so.2 => /usr/lib/libmp.so.2
>
>This looks good to me, but ...
>
>If I type dcgrib, I get the usual output about usage:
>Usage: dcgrib [options] output_file
>Options:
> -h Print the help file, then exit the program
> -v Verbose, report decoding steps
>
>But If I type "dcgrib2", I get the following:
>ld.so.1: dcgrib2: fatal: relocation error: file dcgrib2: symbol __s_rsFe_pv:
>referenced symbol not found
>Killed
>
>I switched the order of my LD_LIBRARY_PATH for user ldm to put
>/ljuka/gemadm/gempak/lib/sol first and that has stopped this problem. The gemp
> ak
>libraries were last before. So the problem was with the libraries, but the out
> put
>of the "ldd" command wasn't telling me that was it?
>
>Here's the output of "ldd" now:
>aspre ldm !% ldd /ljuka/gemadm/gempak/bin/sol/dcgrib2
> libm.so.1 => /ljuka/gemadm/gempak/lib/sol/libm.so.1
> libsocket.so.1 => /usr/lib/libsocket.so.1
> libnsl.so.1 => /usr/lib/libnsl.so.1
> libF77.so.4 => /ljuka/gemadm/gempak/lib/sol/libF77.so.4
> libM77.so.2 => /ljuka/gemadm/gempak/lib/sol/libM77.so.2
> libsunmath.so.1 => /ljuka/gemadm/gempak/lib/sol/libsunmath.so.1
> libc.so.1 => /usr/lib/libc.so.1
> libdl.so.1 => /usr/lib/libdl.so.1
> libmp.so.2 => /usr/lib/libmp.so.2
>
>
>Now that my library path is fixed, the gempak files are being created and ther
> e
>don't seem to be any more errors.
>
>Thanks for your help,
>
>Ruth
>
>
>>
>>
>> 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
>> >
>>
>> ****************************************************************************
>> Unidata User Support UCAR Unidata Program
>> (303)497-8644 P.O. Box 3000
>> address@hidden Boulder, CO 80307
>> ----------------------------------------------------------------------------
>> Unidata WWW Service http://www.unidata.ucar.edu/
>> ****************************************************************************
>