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

[LDM #FPM-496740]: gempak decoders failing



Hi Dave,

In order to test Steve's comment about the reason for the LDM not being able
to run GEMPAK decoders was due to LD_LIBRARY_PATH not being passed to the 
environment
in which the decoders are run (the environment in which 'pqact' runs), I did the
following on twister:

<as 'root'>
cd /lib64
ln -s /usr/local/miniconda/lib/libpython2.7.so.1.0 .
ln -s libpython2.7.so.1.0 libpython2.7.so

<as 'ldm'>
-- comment out the setting of LD_LIBRARY_PATH in ~ldm/.login
unsetenv LD_LIBRARY_PATH
ldmadmin restart

Since making the above changes, all LDM-initiated GEMPAK decoding appear
to be working as they should.  One example:

address@hidden ~]$ ls -alt /data/ldm/gempak/surface
total 5000
-rw-rw-r--  1 ldm programs 5101568 Sep  3 12:39 20160903_sao.gem
drwxrwxr-x  2 ldm programs    4096 Sep  3 12:30 .
-rw-r--r--  1 ldm programs       0 Sep  1 19:50 .scour*
drwxrwxr-x 29 ldm programs    4096 Apr 10  2015 ..

NB:

Steve and I talked to Michael James about the Python lib dependency in the
GEMPAK decoders provided in the v7.x rpms, and, after review, he said that
there should not be any dependency on the Python shared library for the
decoders.  I expect, therefore, that he will be recreating the latest
GEMPAK rpm after getting rid of that dependency (but I have no ETA for
when this may be available).

Final comment:  This was an "interesting" problem :-)

Steve Emmerson wrote:
> Found the problem (I was off-base).
> 
> The GEMPAK decoders require a Python shared library:
> 
> address@hidden etc]$ ldd /home/gempak/GEMPAK7/os/linux64/bin/dcgrib2
> ...
> libpython2.7.so.1.0 => /usr/local/miniconda/lib/libpython2.7.so.1.0 
> (0x00007f92f1435000)
> ...
> 
> and won't work it it can't be found:
> 
> address@hidden etc]$ LD_LIBRARY_PATH= ldd 
> /home/gempak/GEMPAK7/os/linux64/bin/dcgrib2
> ...
> libpython2.7.so.1.0 => not found
> ...
> 
> and the pqact(1) process doesn't have LD_LIBRARY_PATH set:
> 
> address@hidden etc]$ ps -p 13761 -ww e | fgrep LD_LIBRARY_PATH
> address@hidden etc]$
> 
> Probably because ldmadmin(1) is a Perl script and the perl(1) utility deletes 
> that
> environment variable.
> 
> A solution might be to use yum(8) to install the native Python library. It 
> would
> likely be installed in /usr/lib64 and, consequently, found by the dynamic 
> loader.

Cheers,

Tom
--
****************************************************************************
Unidata User Support                                    UCAR Unidata Program
(303) 497-8642                                                 P.O. Box 3000
address@hidden                                   Boulder, CO 80307
----------------------------------------------------------------------------
Unidata HomePage                       http://www.unidata.ucar.edu
****************************************************************************


Ticket Details
===================
Ticket ID: FPM-496740
Department: Support LDM
Priority: Normal
Status: Closed
===================
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.



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.