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

[LDM #VVR-781619]: ldm failure

Hi Chris,

re: consolidate feed requests; make redundant patterns unique; upgrade LDM

> Thanks Tom, I will see if this works.

Very good.

> If I upgrade to 6.6.5, does it
> work like GEMPAK where I just need to repoint the symlink to the newest
> version folder or do I actually need to configure/change anything else?

Upgrading the LDM is very easy.  Here is a blow-by-blow that _assumes_
that your current LDM is correctly installed:

<login as 'ldm'>

cd ~ldm
ftp ftp.unidata.ucar.edu
  <user> anonymous
  <pass> address@hidden
  cd pub/ldm
  binary
  get ldm-6.6.5.tar.gz
  quit

zcat ldm-6.6.5.tar.gz | tar xvf -

cd ldm-6.6.5/src
./configure
make
make install
sudo make install_setuids       <- important!  you need 'root'
                                   privilege to finish the installation
                                   correctly!!

cd ~ldm

ldmadmin stop
rm runtime
ln -s ldm-6.6.5 runtime

ldmadmin start


It is _very) important that you finish the LDM installation by running
'make install_setuids' as 'root' from the ~ldm/ldm-6.6.5/src directory.
We see too many instances where the LDM administrator skips this last
step and then starts seeing errors with logging, contact to upstream
LDMs, etc.

re:
> I'm fairly clueless as to what's wrong with the GEMPAK decoding
> problems.  I haven't changed anything since it last worked except for
> the ldmd.conf file, and I'm really not sure where to look for a problem
> with decoding.

It would be difficult to introduce a problem with GEMPAK decoding by
making a modification to ldmd.conf.  You could, of course, accidentally
delete a feed request, but that would simply result in one or more
decoders no longer being run.  It would not show up as a decoding
error.

> I made the modifications to ldmd.conf that you recommended, and so far,
> my ldm has not crashed again yet. Which is good.

I agree.  Consolidating your feed requests would also decrease the processing
load on your machine and your upstream feeders.   This is always good.

> However, I am still
> getting lots of the 'exited with status 1' messages that I was before.

OK, but are they from feed request processes, or are they from decode actions?

If you give us a login to your machine as 'ldm' and 'gempak', we could take
a quick look around to see what may be happening.  If you decide that this
is OK and what you want, please send the passwords ** without reference to
the accounts they go with ** and ** without reference to the machine they
are valid on ** to my personal email address, address@hidden.

> Thanks,

No worries.

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