20041022: ldmd.conf error messages (cont.)

>From: Robert Dewey <address@hidden>
>Organization: ?
>Keywords: 200410220550.i9M5oYvV023578 GEMPAK

Robert,

>Nope, didn't upgrade after the outage, could this be the problem?

No, I was just asking to see if you had upgraded and perhaps forgotten
something that was needed.

>Anyway, just after I sent this message last night, I started getting 
>other errors messages, and data disruption (see below for error 
>messages), which doing a search through the Unidata archives reveals 
>that it maybe a network issue. I decided to ping the main feed - 
>bigbird.tamu.edu - I set ping for a count of 50 packets, it returned 49 
>packets, so that's a 2% packet loss, I repeated this process a few times 
>on Bigbird, with the max packet loss being 6% (which I don't like to 
>see). I pinged the other feed - weather.cod.edu - They returned all 50 
>packets, repeated the process for google.com and yahoo.com - Both 
>returned 100% of the packets, pinged www.rap.ucar.edu, also returned all 
>50 packets. I am not sure if it's just a coincidence or what, but in the 
>error logs "Bigbird" shows up many more times than 
>weather3.admin.niu.edu and weather.cod.edu (which doesn't show up at all 
>due to the very small feed request, on the order of 5-10mb/hour)

This sounds like there is a network problem between you and Texas A&M
(home of bigbird.tamu.edu).

> If it turns out to be the network issue, could this also be causing the 
>original error messages as far as the decoder problems?

While network interruptions are not good, the LDM will guarantees delivery
of data products as long as the interruption is shorter than the span
of time of data products in the upstream LDM queue (which is typically
at least one hour).

>It just struck 
>me as odd that the machine was running perfectly until the outage (in 
>which the machine was powered down), so nothing has changed 
>software-wise,  yet this is the first time these errors appeared...

The error you first reported is a write error on the local system.
Did you check to make sure that the directory into which the GEMPAK
decoders are supposed to write are still writable by the user running
your LDM?

>I am going to upgrade to GEMPAK 5.7.3 this evening, and then mess around 
>with network configuration a bit (primarily bypassing the router and 
>using a direct connection) to see if that changes anything - If it 
>doesn't then that would mean the problem was either further out on the 
>network (the ISP), or somehow a problem that "developed" within the LDM 
>server, such as an O/S problem or something similar.

Again, the write error should not be related to your network 
connectivity.  It is being caused by one of the three possibilities
I mentioned in the previous email.

>Error messages from ldmd.log ( I also attached the file itself to this 
>e-mail - about 45KB in size, ldmd.log.1 ), I also put the "interesting" 
>parts below, in case you prefer not to deal with the attachment...
>
>Oct 22 07:49:48 LDM bigbird[3881]: ERROR: requester6.c:206: Connection to upst
> ream LDM closed 

This kind of message _is_ a result of bad network connectivity.

>Thanks for the help!

No worries.

Cheers,

Tom
--
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.