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

[LDM #OGC-117993]: Failed to get data from idd.cise-nsf.gov

Hi David,

re:
> I have added the
> 
> exec    "rtstats -h rtstats.unidata.ucar.edu"
> 
> to ldmd.conf file and restart it.

Thanks.  Getting real time stats will help us in troubleshooting problems.

> The "nslookup rtstats.unidata.ucar.edu" works ok.

Very good.

> I have also run the delete queue and mkqueue to restart the ldm.

OK.  This will eliminate the possibility of a corrupt queue.

> Then, I have tried the "notifyme -vxl- -f IDS -h idd.unidata.ucar.edu"
> and returns lots of output until I interrupt it by ^C. Here are the
> output:
> 
> [ldm@rcz006 etc]$ notifyme -vxl- -f IDS -h idd.unidata.ucar.edu
> Feb 02 08:46:56 notifyme[3388] NOTE: Starting Up: idd.unidata.ucar.edu: 
> 20070202084656.208 TS_ENDT {{IDS,  ".*"}}
> Feb 02 08:46:56 notifyme[3388] NOTE: LDM-5 desired product-class: 
> 20070202084656.208 TS_ENDT {{IDS,  ".*"}}
> Feb 02 08:46:56 DEBUG: NOTIFYME(idd.unidata.ucar.edu) returns OK
> Feb 02 08:46:56 notifyme[3388] NOTE: NOTIFYME(idd.unidata.ucar.edu): OK
> Feb 02 08:46:58 notifyme[3388] INFO: cb6197be0cf98be88d4bde2596a926e2      
> 170 20070202084658.092 IDS|DDPLUS 88729934  SSVX08 KARS
> 020800
> Feb 02 08:47:00 notifyme[3388] INFO: 07840a49838bc38cda659f2f142f0b3b      
> 180 20070202084700.403 IDS|DDPLUS 88729947  SSVX10 KARS
> 020600 RRB
> Feb 02 08:47:01 notifyme[3388] INFO: 6a7e9cb142c802dccba31f6672fbb334      
> 792 20070202084700.405 IDS|DDPLUS 88729948  SSVX02 KARS
> 020818
> Feb 02 08:47:01 notifyme[3388] INFO: 445ffdb77486dfd28711f2b76ca87bb9      
> 180 20070202084700.408 IDS|DDPLUS 88729949  SS
> ...
> 
> Are these messages normal?

Yes.  This shows that your machine is allowed to request data from 
idd.unidata.ucar.edu
(we already knew this, but it is good to reaffirm), and that it can receive
LDM messages from said machine.  Since this works, you _should_ be able to
receive data.

> But I still don't seem the data coming.

Hmm... The only other thing that comes to mind is your system clock.  If it
is far off, your ldmd.conf feed requests might be requesting from some time
in the future.  Can you verify that your clock is accurate?  Are you running
something like ntpd to set the clock?

If your clock is way off, starting the LDM telling it to not go back in
time might get you going:

ldmadmin stop
ldmadmin start -o 1

Hmm, as I wrote the above it dawned on me that if your clock is off, going
back one minute (the '-o 1') won't do any good.

If you are not running ntpd, try running ntpdate as follows:

<as 'root'>
ntpdate timeserver.unidata.ucar.edu

If you are running 'ntpd', then I suggest killing it and running 'ntpdate'
as I indicate above.

'ntpdate' will do a one-time setting of your clock, so running it instead of
'ntpd' is not a cure-all.

One last question:  how do you know that you are not receiving data?  What
I mean by this (I am not trying to be flip) is that if you are judging
receipt of data by processing you have setup in your ~ldm/etc/pqact.conf file,
then you may get fooled into believing that you are not receiving data
since nothing is being processed (due to an error in pqact.conf?).  To test
this possibility, run the following while the LDM is running:

ldmadmin watch

What are the results of this?

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