[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[IDD #EEH-918211]: LDM - Network Issues...
- Subject: [IDD #EEH-918211]: LDM - Network Issues...
- Date: Tue, 01 May 2007 13:23:49 -0600
Hi Mike,
re:
> 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:
*.info;mail.none;news.none;authpriv.none;cron.none;local0.none
/var/log/messages
and
# LDM
local0.* /usr/local/ldm/logs/ldmd.log
the whitespace between 'none' and '/var/log/messages' and that between
'local0.*'
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
syslog'
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,
then
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
supply
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
yesterday
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
looking
into the problem and will let you know as soon as it is resolved. Thank you
for
your patience.
Paul Madden
NOAA/ESRL/GSD
As of 13:10 Z, MADIS data are available again.
Paul Madden
NOAA/ESRL/GSD
> 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
above.
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
./configure
make
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:
[wxmanldm@godelsrevenge ~]$ 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 137.75.133.23 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:
[wxmanldm@godelsrevenge ~]$ notifyme -vxl- -f FSL2 -h eldm.fsl.noaa.gov -o 3600
-p "^FSL\.CompressedNetCDF\."
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
137.75.133.23 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
FSL.CompressedNetCDF.MADIS.radiometer.20070501_1400.gz
shows:
- 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
(corrected
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)"
eldm.fsl.noaa.gov
REQUEST FSL2
"^FSL\.CompressedNetCDF\.MADIS\.(radiometer|HDW|HDW1h}mesonet2|hydro2)"
eldm.fsl.noaa.gov
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: EEH-918211
Department: Support IDD
Priority: Normal
Status: Closed