[IDD #IFM-792517]: moving LDM to a new host server

Hi Sevtlin,

re:
> Thanks a lot. I fix this problem. So now we have something in ldmd.log

Excellent.

> Here is the output.
> 
> [ldm@pleiades logs]$ more ldmd.log
> Nov 12 20:22:15 pleiades rpc.ldmd[1066] NOTE: Starting Up (version: 6.6.5;
> built: Jul  5 2007 14:33:23)
> Nov 12 20:22:15 pleiades rpc.ldmd[1066] NOTE: Using local address
> 0.0.0.0:388
> Nov 12 20:22:15 pleiades pqact[1068] NOTE: Starting Up
> Nov 12 20:22:15 pleiades idd.cise-nsf.gov[1070] NOTE: Starting Up(6.6.5):
> idd.cise-nsf.gov:388 20071112192215.104 TS_ENDT {{NNEXRAD,  ".*"}}
> Nov 12 20:22:15 pleiades idd.cise-nsf.gov[1070] NOTE: LDM-6 desired
> product-class: 20071112192215.106 TS_ENDT {{NNEXRAD,  ".*"},{NONE,
> "SIG=c30b6d25f0caf2a111182c7509345e4e"}}
> Nov 12 20:22:15 pleiades pqact[1068] NOTE: Starting from insertion-time
> 2007-11-12 20:20:18.529362 UTC
> Nov 12 20:22:15 pleiades idd.cise-nsf.gov[1071] NOTE: Starting Up(6.6.5):
> idd.cise-nsf.gov:388 20071112192215.108 TS_ENDT {{UNIWISC,  ".*"}}
> Nov 12 20:22:15 pleiades idd.cise-nsf.gov[1071] NOTE: LDM-6 desired
> product-class: 20071112192215.109 TS_ENDT {{UNIWISC,  ".*"},{NONE,
> "SIG=57d3d1688741b796113a20de2c1c0280"}}
> Nov 12 20:22:15 pleiades idd.unidata.ucar.edu[1073] NOTE: Starting Up(6.6.5):
> idd.unidata.ucar.edu:388 20071112192215.111 TS_ENDT {{CONDUIT,
> "data/nccf/com/nam"}}
> Nov 12 20:22:15 pleiades idd.unidata.ucar.edu[1073] NOTE: LDM-6 desired
> product-class: 20071112192215.112 TS_ENDT {{CONDUIT,
> "data/nccf/com/nam"},{NONE,  "SIG=4adfff089a1e568ab0
> a2459940b48e3c"}}
> Nov 12 20:22:15 pleiades idd.cise-nsf.gov[1072] NOTE: Starting Up(6.6.5):
> idd.cise-nsf.gov:388 20071112192215.110 TS_ENDT {{FSL2,  ".*"}}
> Nov 12 20:22:15 pleiades idd.unidata.ucar.edu[1074] NOTE: Starting Up(6.6.5):
> idd.unidata.ucar.edu:388 20071112192215.114 TS_ENDT {{DDPLUS,  ".*"}}
> Nov 12 20:22:15 pleiades idd.cise-nsf.gov[1072] NOTE: LDM-6 desired
> product-class: 20071112192215.115 TS_ENDT {{FSL2,  ".*"},{NONE,
> "SIG=f00d23c0de12d7f69ff056d896f1fe5f"}}
> Nov 12 20:22:15 pleiades idd.unidata.ucar.edu[1074] NOTE: LDM-6 desired
> product-class: 20071112192215.115 TS_ENDT {{DDPLUS,  ".*"},{NONE,
> "SIG=28cd415a9fde2be8c8e4ee28ad5a5d49"}
> }
> Nov 12 20:22:15 pleiades rtstats[1069] NOTE: Starting Up (1066)
> Nov 12 20:22:15 pleiades idd.unidata.ucar.edu[1074] NOTE: Upstream LDM-6 on
> idd.unidata.ucar.edu is willing to be a primary feeder
> Nov 12 20:22:15 pleiades idd.unidata.ucar.edu[1073] NOTE: Upstream LDM-6 on
> idd.unidata.ucar.edu is willing to be a primary feeder
> Nov 12 20:25:24 pleiades idd.cise-nsf.gov[1070] ERROR: Disconnecting due to
> LDM failure; Couldn't connect to LDM on idd.cise-nsf.gov using either port
> 388 or portmapper; : RPC: R
> emote system error - Connection timed out
> Nov 12 20:25:24 pleiades idd.cise-nsf.gov[1070] NOTE: LDM-6 desired
> product-class: 20071112192524.184 TS_ENDT {{NNEXRAD,  ".*"},{NONE,
> "SIG=c30b6d25f0caf2a111182c7509345e4e"}}
> Nov 12 20:25:24 pleiades idd.cise-nsf.gov[1071] ERROR: Disconnecting due to
> LDM failure; Couldn't connect to LDM on idd.cise-nsf.gov using either port
> 388 or portmapper; : RPC: R
> emote system error - Connection timed out
> Nov 12 20:25:24 pleiades idd.cise-nsf.gov[1071] NOTE: LDM-6 desired
> product-class: 20071112192524.186 TS_ENDT {{UNIWISC,  ".*"},{NONE,
> "SIG=57d3d1688741b796113a20de2c1c0280"}}
> Nov 12 20:25:24 pleiades idd.cise-nsf.gov[1072] ERROR: Disconnecting due to
> LDM failure; Couldn't connect to LDM on idd.cise-nsf.gov using either port
> 388 or portmapper; : RPC: R
> emote system error - Connection timed out
> Nov 12 20:25:24 pleiades idd.cise-nsf.gov[1072] NOTE: LDM-6 desired
> product-class: 20071112192524.192 TS_ENDT {{FSL2,  ".*"},{NONE,
> "SIG=f00d23c0de12d7f69ff056d896f1fe5f"}}

This output shows a couple of things:

- you are unable to contact idd.cise-nsf.gov.  This turns out to be
  a problem with idd.cise-nsf.gov, not with you.  You can determine
  this using the LDM utility 'ldmping':

  <as 'ldm'>
  ldmping idd.cise-nsf.gov

  If you don't get a message that the LDM on idd.cise-nsf.gov is
  responding, you know that there is a problem with it

- your request for CONDUIT data is limited to product headers that
  match 'data/nccf/com/nam'.  You can determine if there are any
  products whose headers will match this pattern using the LDM
  utility 'notifyme':

  <as 'ldm'>
  notifyme -vxl- -f CONDUIT -h idd.unidata.ucar.edu -o 10000 -p 
'data/nccf/com/nam'

  If your 'notifyme' invocation listing does not show that the upstream host
  (idd.unidata.ucar.edu) has the data, then you will not/can not get the data.

  Here is the result of such a 'notifyme' invocation from my machine's LDM to
  idd.unidata.ucar.edu:

[ldm@yakov ~]$ notifyme -vxl- -f CONDUIT -h idd.unidata.ucar.edu -o 10000 -p 
'data/nccf/com/nam'

  So, idd.unidata.ucar.edu _does_ have the data.  The next question is if you 
are receiving
  the data.  You can once again use 'notifyme':

  <as 'ldm' on pleiades>
  notifyme -vxl- -f CONDUIT -o 10000 -p 'data/nccf/com/nam'
[ldm@pleiades ~]$ notifyme -vxl- -f CONDUIT -o 10000 -p 'data/nccf/com/nam'
Nov 12 21:44:48 notifyme[1729] NOTE: Starting Up: localhost: 20071112185808.749 
TS_ENDT {{CONDUIT,  "data/nccf/com/nam"}}
Nov 12 21:44:48 notifyme[1729] NOTE: LDM-5 desired product-class: 
20071112185808.749 TS_ENDT {{CONDUIT,  "data/nccf/com/nam"}}
Nov 12 21:44:48 notifyme[1729] INFO: Resolving localhost to 127.0.0.1 took 
0.000777 seconds
Nov 12 21:44:48 DEBUG: NOTIFYME(localhost) returns OK
Nov 12 21:44:48 notifyme[1729] NOTE: NOTIFYME(localhost): OK
Nov 12 21:44:49 notifyme[1729] INFO: f4fad2ff92ce4967f4f710b484f221bc    20976 
20071112202218.900 CONDUIT 011  
data/nccf/com/nam/prod/nam.20071112/nam.t18z.awip3d18.tm00_icwf 
!grib/ncep/NMM_89/#212/200711121800/F018/CPOFP/sfc! 000011
Nov 12 21:44:49 notifyme[1729] INFO: 42ab04e96f7f4aaf569c09f2012b3b05    29926 
20071112202224.075 CONDUIT 001  
data/nccf/com/nam/prod/nam.20071112/nam.t18z.awip3d27.tm00_icwf 
!grib/ncep/NMM_89/#212/200711121800/F027/TMAX/2_m_above_gnd! 000001
Nov 12 21:44:49 notifyme[1729] INFO: a7fbce0ebc729ba5d3bd796b393e3154    20976 
20071112202224.078 CONDUIT 008  
data/nccf/com/nam/prod/nam.20071112/nam.t18z.awip3d27.tm00_icwf 
!grib/ncep/NMM_89/#212/200711121800/F027/TCDC/atmos_col! 000008
Nov 12 21:44:49 notifyme[1729] INFO: a2f60df1b9dfbe3aff3ccfca85cbad11    20976 
20071112202224.079 CONDUIT 011  
data/nccf/com/nam/prod/nam.20071112/nam.t18z.awip3d27.tm00_icwf 
!grib/ncep/NMM_89/#212/200711121800/F027/CPOFP/sfc! 00001
 ...

  So, this shows that you are also getting the data that you requested.  The 
question now is if you
  are processing the data that you want to process?

Your ~ldm/etc/ldmd.conf file indicates that you are running one invocation of 
'pqact' and
that invocation uses the file ~ldm/etc/pqact.conf for its set of 
pattern-actions.  Examination
of ~ldm/etc/pqact.conf shows that the entry you created to process the CONDUIT 
data (CONDUIT
is the preferred name for the feed also known as NMC2):

#########################################################################
#
# NMC2 section
#
#########################################################################
NMC2    ^data/nccf/com/nam/prod/nam.(.*)/nam.t(.*)z.awip3d(.*).tm00 !(.*)!
FILE    data/nmc2/eta40grb.\1\2f\3


I decided to use the LDM facility for checking the integrity of pattern action 
files:

<as 'ldm' on pleiades>
cd ~ldm
ldmadmin pqactcheck
/home/ldm/etc/pqact.conf is syntactically correct

OK, but the pattern specified in your pqact.conf pattern-action file uses a
much more strict pattern for matching CONDUIT products than what is being 
requested
from the upstream host: 
'^data/nccf/com/nam/prod/nam.(.*)/nam.t(.*)z.awip3d(.*).tm00 !(.*)!'
The question is if it will match anything that is being received?  Here's how 
to test this:

[ldm@pleiades ~]$ notifyme -vxl- -f CONDUIT -o 10000 -p 
'^data/nccf/com/nam/prod/nam.(.*)/nam.t(.*)z.awip3d(.*).tm00 !(.*)!'
Nov 12 21:54:20 notifyme[1855] NOTE: Starting Up: localhost: 20071112190740.706 
TS_ENDT {{CONDUIT,  
"^data/nccf/com/nam/prod/nam.(.*)/nam.t(.*)z.awip3d(.*).tm00 !(.*)!"}}
Nov 12 21:54:20 notifyme[1855] NOTE: LDM-5 desired product-class: 
20071112190740.706 TS_ENDT {{CONDUIT,  
"^data/nccf/com/nam/prod/nam.(.*)/nam.t(.*)z.awip3d(.*).tm00 !(.*)!"}}
Nov 12 21:54:20 notifyme[1855] INFO: Resolving localhost to 127.0.0.1 took 
0.000876 seconds
Nov 12 21:54:20 DEBUG: NOTIFYME(localhost) returns OK
Nov 12 21:54:20 notifyme[1855] NOTE: NOTIFYME(localhost): OK

After waiting a number of minutes, I see no matches.  This means that the 
pattern being
used does not match any CONDUIT product that you are receiving (or that are on 
the up
stream feed host since I used a notifyme to it and saw nothing), hence you get 
nothing
FILEd to disk.

Question:

- did this pattern _ever_ match any products in the CONDUIT datastream?

Even if it once did, it doesn't now!  I would review the list of products 
coming in
(notifyme -vxl- -f CONDUIT) to see if the products you were once FILEing are no
longer in the datastream.

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: IFM-792517
Department: Support IDD
Priority: Normal
Status: Closed