This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.
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