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

[IDD #EEH-918211]: LDM - Network Issues...

Hi Mike,

> Hmmm.  This continues to get curioser and curioser...
> All the /etc/sys... files were OK.  I changed them when reinstalling
> LDM.  Then I checked them twice more, just to be sure.  All permissions
> seem to be OK, so I checked them again and they are OK.  pedant (the
> daemon) runs OK on start up (I checked) and continues to run and the
> time is correct.

Did you make sure that the whitespace used in /etc/syslog.conf were tabs,
not spaces?  What I mean is that in the lines:



local0.*                                        /usr/local/ldm/logs/ldmd.log

the whitespace between 'none' and '/var/log/messages' and that between 
and '/usr/local/ldm/logs/ldmd.log' should all be tabs, not spaces.  Also, after
editing /etc/syslog.conf, one must send a HUP signal to the syslogd daemon so
it will reread the configuration file.

Furthermore, the syslogd daemon must be running.  A quick 'ps -eaf | grep 
will show if it is running or not.  If it isn't, then one must find out why it
isn't running, and there are two possibilities:

- it was not setup to run on boot
- it exited/crashed for some reason

If the first option is the problem, then 'root' should do the following:

chkconfig --levels 345 syslogd on
/etc/init.d/syslogd start

Finally, if 'syslogd' is running, and /etc/syslog.conf is properly configured, 
one can use the Linux 'logger' utility to test logging to ~ldm/logs/ldmd.log:

<as 'ldm'>
logger -p local0.debug 'test of LDM logging'

If everything is setup correctly, then you should see the 'test of LDM logging'
message in the ~ldm/logs/ldmd.log file.

> I noticed an e-mail from Mike Barth at FL just a little after sending
> you guys the emails and he notes the OpenDAP server is back up running
> (I didn't know it was down, but suspected it when pinging it last night
> then trying to login) but that wouldn't have anything to do with my
> issues now.

I wouldn't think that the OPeNDAP server would have anything to do with the 
of MADIS data through an LDM feed (but I could be wrong).  I didn't consider
lack of MADIS data in our exchanges since a pair of emails from NOAA/GSD 
indicated that it was back up after being unavailable for awhile:

  Date:    Mon, 30 Apr 2007 06:53:23 MDT
  To:      address@hidden, address@hidden, address@hidden

  From:    Paul Madden <address@hidden>
  Subject: MADIS NOAA data currently unavailable

  From address@hidden  Mon Apr 30 06: 53:55 2007

  MADIS NOAA data are currently unavailable on the GSD ftp server. We are 
  into the problem and will let you know as soon as it is resolved. Thank you 
  your patience.

  Paul Madden

  As of 13:10 Z, MADIS data are available again.

  Paul Madden

> So I ran ldmadmin start, all the pings, notifyme, etc.  The pings don't
> indicate much, but several of the other messages do.  They're down
> toward the bottom of the "ping_etc_again" file and their seems to be an
> issue with /var/run/hupsyslog or whatever it's called.  Take a look.  I
> also checked the issue and corrected it regarding the other syslog file
> in /etc. but the "hup" file message?

> I'll attach all of this and the pqact.conf and lmd.conf as well as
> ldmd-pl.conf.
> Suggestions?

The message:

hupsyslog: couldn't open /var/run/syslogd.pid

might indicate that syslogd is not running. Setup syslogd to run as outlined 

However, the comment:

hupsyslog: kill -HUP 2156: Permission denied

indicates that the last step in the build/install of the LDM was not done:

<as 'ldm'>
cd ~ldm/ldm-6.6.3/src
make install
sudo make install_setuids       <- the last step is to set the owner of 
rpc.ldmd and hupsyslog
                                   to be 'root'

You can verify if this step was not done by:

cd ~ldm
ls -alt bin/hupsyslog
ls -alt bin/rpc.ldmd

If both are owned by 'ldm', then do the following:

cd ~ldm/ldm-6.6.3/src
sudo make install_setuids        <- if your system is setup with 'sudo'

-- or equivalently --

su                               <- NB: 'su' NOT 'su -'
make install_setuids

Finally, your ~ldm/etc/ldmd.conf file shows that you are trying to request
data from 'eldm.fsl.gov'.  The NOAA/GSD machine's name is 'eldm.fsl.noaa.gov'.
Your 'ldmping' and 'notifyme' examples are correctly to 'eldm.fsl.noaa.gov'.

Some comments for future consideration:

- while doing a 'ping' to the machine might be helpful, it also might not since
  lots of sites turn off ping responses.  Not getting a response to a ping
  should not necessarily, therefore, be interpreted to mean that the machine
  being pinged is not accessible

- the positive response by eldm to ldmping:

address@hidden ~]$ ldmping -i 5 -h eldm.fsl.noaa.gov
May 01 16:02:49 INFO: State Elapsed Port Remote_Host rpc_stat
May 01 16:02:49 INFO: Resolving eldm.fsl.noaa.gov to took 
0.052634 seconds
May 01 16:02:49 INFO: RESPONDING 0.265592 388 eldm.fsl.noaa.gov

  conclusively shows that the LDM on eldm is running.

- the 'notifyme' to eldm:

address@hidden ~]$ notifyme -vxl- -f FSL2 -h eldm.fsl.noaa.gov -o 3600 -p 
May 01 16:06:06 notifyme[3881] NOTE: Starting Up: eldm.fsl.noaa.gov: 
20070501150606.232 TS_ENDT {{FSL2, "^FSL\.CompressedNetCDF\."}}
May 01 16:06:06 notifyme[3881] NOTE: LDM-5 desired product-class: 
20070501150606.232 TS_ENDT {{FSL2, "^FSL\.CompressedNetCDF\."}}
May 01 16:06:06 notifyme[3881] INFO: Resolving eldm.fsl.noaa.gov to took 0.052996 seconds
May 01 16:06:06 DEBUG: NOTIFYME(eldm.fsl.noaa.gov) returns OK
May 01 16:06:06 notifyme[3881] NOTE: NOTIFYME(eldm.fsl.noaa.gov): OK
May 01 16:06:07 notifyme[3881] INFO: 44bc75b169af6fb9ba8b5852ea73f6e4 59238 
20070501150606.431 FSL2 000 


   - eldm is accessible
   - the LDM on eldm is running
   - the LDM on eldm is configured to allow you to request data

- the multiple request lines you have for MADIS data in ~ldm/etc/ldmd.conf 
  to use the correct name for the LDM machine at NOAA/GSD):

REQUEST FSL2 "^FSL\.CompressedNetCDF\.RSAS" eldm.fsl.noaa.gov
REQUEST FSL2 "^FSL\.CompressedNetCDF\.MADIS\.metar" eldm.fsl.noaa.gov
REQUEST FSL2 "^FSL\.CompressedNetCDF\.MADIS\.sao" eldm.fsl.noaa.gov
REQUEST FSL2 "^FSL\.CompressedNetCDF\.MADIS\.snow" eldm.fsl.noaa.gov
REQUEST FSL2 "^FSL\.CompressedNetCDF\.MADIS\.raob" eldm.fsl.noaa.gov
REQUEST FSL2 "^FSL\.CompressedNetCDF\.MADIS\.radiometer" eldm.fsl.noaa.gov
REQUEST FSL2 "^FSL\.CompressedNetCDF\.MADIS\.HDW" eldm.fsl.noaa.gov
REQUEST FSL2 "^FSL\.CompressedNetCDF\.MADIS\.HDW1h" eldm.fsl.noaa.gov
REQUEST FSL2 "^FSL\.CompressedNetCDF\.MADIS\.mesonet2" eldm.fsl.gov
REQUEST FSL2 "^FSL\.CompressedNetCDF\.MADIS\.hydro2" eldm.fsl.gov

   could be combined into a fewer number of requests.  This would decrease the
   number of processes running on your machine, AND, probably more importantly
   decrease the number of processes running on the NOAA/GSD machine.

The following reduction in feed requests should work nicely:

REQUEST FSL2 "^FSL\.CompressedNetCDF\.RSAS" eldm.fsl.noaa.gov
REQUEST FSL2 "^FSL\.CompressedNetCDF\.MADIS\.(metar|sao|snow|raob)" 


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

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.