[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[IDD #IFM-792517]: moving LDM to a new host server
- Subject: [IDD #IFM-792517]: moving LDM to a new host server
- Date: Mon, 12 Nov 2007 15:01:39 -0700
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