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

[LDM #HZO-576656]: LDM install

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 #HZO-576656]: LDM install
  • Date: Wed, 30 Oct 2013 13:37:01 -0600
Hi Steve,

re:
> Hey there - I was wondering if you guys (Steve E?  Tom Y?  ) could do a 
> reinstall of LDM
> on our virtual machine (cumulus.dmes.fit.edu<http://cumulus.dmes.fit.edu>, 
> 163.118.170.80)
> here at FIT?

After our phone conversation today, I logged on to cumulus and installed the
latest LDM-6 release, ldm-6.11.6, from source.  The installation went smoothly
enough, but I needed to do the following additional steps to move up to the
current LDM release:

- install the libxml2-devel code

  <as 'root'>
  yum install libxml2-devel

  This is needed because the xml2 code is no longer bundled with the LDM.  This
  is better since the maintainers of the OS are better keeping on top of the
  latest libxml2 and libxml2-devel releases.

- removed a define for LD_LIBRARY_PATH in 'ldm's .bash_profile file

Before starting the newly built LDM, I verified that the GEMPAK decoders
that are accessed through the PATH definition for 'ldm' were runable:

<as 'ldm'>
-- after the LD_LIBRARY_PATH definition in ~ldm/.bash_profile was commented
   out and I had logged off and then back on as 'ldm'

$ ldd `which demetr`
        linux-vdso.so.1 =>  (0x00007fff20fff000)
        libgfortran.so.3 => /usr/lib64/libgfortran.so.3 (0x00007f0869aa6000)
        libm.so.6 => /lib64/libm.so.6 (0x0000003581c00000)
        libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x0000003583c00000)
        libc.so.6 => /lib64/libc.so.6 (0x0000003580c00000)
        /lib64/ld-linux-x86-64.so.2 (0x0000003580800000)

I also verified that the system-installed xml2 shared library will be used
for LDM routines:

$ ldd bin/ldmd
        linux-vdso.so.1 =>  (0x00007fff86fd5000)
        libldm.so.0 => /home/ldm/ldm-6.11.6/lib/libldm.so.0 (0x00007f2c87863000)
        libxml2.so.2 => /usr/lib64/libxml2.so.2 (0x0000003587c00000)
        libz.so.1 => /lib64/libz.so.1 (0x0000003581800000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x0000003581400000)
        libm.so.6 => /lib64/libm.so.6 (0x0000003581c00000)
        libc.so.6 => /lib64/libc.so.6 (0x0000003580c00000)
        libdl.so.2 => /lib64/libdl.so.2 (0x0000003581000000)
        /lib64/ld-linux-x86-64.so.2 (0x0000003580800000)

I ran a simple 'ps -u ldm' to verify that the LDM is running and decoders are
active.

I then checked to see if there was any indications of problems in feed
REQUESTs by reviewing entries in the LDM log file:

less ~ldm/logs/ldmd.log

I see problems requesting data from:

suomildm1.cosmic.ucar.edu
eldm.fsl.noaa.gov

Other than that, thing seem to be running.  Please let me know if you see
anything amiss...

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: HZO-576656
Department: Support LDM
Priority: Normal
Status: Closed