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

20040518: LDM problem: Denying connection from localhost.loca l domain

Rodney,

>Date: Thu, 27 May 2004 15:42:58 -0700
>From: "Jacques, Rodney" <address@hidden>
>Organization: US NAVY/NAVPACMETOCCEN
>To: "'Steve Emmerson'" <address@hidden>
>Subject: RE: 20040518: LDM problem: Denying connection from localhost.loca l 
>domain 
> Keywords: 200405121919.i4CJJRtK023189

The above message contained the following:

> Thanks for the help. I have attached a current ldmd.log file for you to look
> at. There is an error in the file.
> 
> ERROR: requester6.c:459 couldn't connect to LDM 6 on galileo    ....or...
> ERROR: requester6.c:459 couldn't connect to LDM 6 on eldm4.fsl.noaa.gov
> 
> Will these cause any problems?

I noticed those.  They indicate that hosts Galileo and Eldm4 are
unavailable (e.g., they could be offline).  Later in the logfile,
however, are entries indicating successful connection to the two hosts.
I don't know what the story is regarding Galieo and Eldm4.  I suggest
that you keep an eye on the logfile and try ping(1)ing the hosts when
the LDM indicates that they're unavailable.  You might want to get a
network administrator involved.

You can check on the status of connections via the command

    netstat -a -t | grep ldm

I seem to recall that FSL uses two computers for Eldm4 and periodically
switches between them.  In that case, Eldm4 would be unavailable during
the switchover.  You might check with FSL.

BTW, Granite's clock is about 16 minutes slow.  The LDM depends on the
host computer having an accurate clock.  I strongly suggest you get it
fixed.  A good solution is for root to run ntpdate(1) periodically
(e.g., every hour).

> And lastly...
> 
> It appears that the ldm is receiving data but 
> the ldm was not writing data to my file directories.????

There's an entry in the LDM logfile indicating that a pqact(1) process
was started.  That's good.  An "ldmadmin ps" shows the pqact(1) process
running.  That's good.

I put the pqact(1) process into verbose-logging mode by sending it a
USR2 signal, e.g.,
    
    kill -USR2 2758

Another such signal will put it into debug-logging mode and a third such
signal will return it to normal logging mode.

Verbose logging by the pqact(1) process will tell you whenever it sees a
data-product upon which it should act.

I don't know those data-streams at all, so all I can suggest is that you
get some idea of how often the data-products of interest arrive and make
sure the extended regular-expressions in the pqact.conf file are
correct.

Keep me apprised.

Regards,
Steve Emmerson