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

[LDM #MKY-400850]: Continuing issue with no TIRC headers getting into secondary LDM box

Hi Gilbert,

re:
> This is true, but when you do this for 30 minutes and that get anything, it’s 
> safe to
> say that nothing is coming in.

Sounds reasonable!  I must say that I have never had the patience to wait for 30
minutes when running 'notifyme' interactively :-)

re:
> And it’s really weird: when we feed from our satellite
> dish, or from Patrick Francis’ satellite dish at modelweather.com, we do not 
> get the
> GOES-16 products on NOTHER. And yet, we get all the other products from 
> NOAAport just
> fine on our server and Patrick’s!

That is totally weird indeed!

re:
> Get this: when we feed from the College of DuPage, we get everything fine.

That matches our experience with downstreams of the top level IDD relays we 
operate,
idd.unidata.ucar.edu and its backup iddb.unidata.ucar.edu never report not 
getting
data ** unless there is some problem with a stale feed process **.  This happens
rarely enough that I hesitated to even mention it.

re:
> We have
> synced all of our servers, including bird01, our satellite ingester, first to 
> Google’s
> server, and then to others that are stratum one or two, restarting NTP each 
> time, and
> even rebooting the server, but it makes no difference! I’m stumped.

The thing about keeping servers synced is so that when (re)establishing a 
connection
the "send me the products from 'n' seconds ago" does not get waylaid by there
being a difference in the clocks on the up and downstream machines.  Once a
connection is established AND DOES NOT BREAK, data should continue to flow
unless there is a problem.

I am sure that Steve will ask for the output from the LDM log files on both
the upstream and downstream machines that cover the situation where data
is flowing and then stops.  This is the only way that the cessation of
flow can be troubleshot.  And it may be necessary to have the upstream
LDM logging in verbose mode (ouch!) when the failure (meaning cessation
of product movement) happens.

Other than what I said in this and the previous email, I'm totally out
of ideas :-(

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: MKY-400850
Department: Support LDM
Priority: Normal
Status: Open
===================
NOTE: All email exchanges with Unidata User Support are recorded in the Unidata 
inquiry tracking system and then made publicly available through the web.  If 
you do not want to have your interactions made available in this way, you must 
let us know in each email you send to us.