[IDD #BOD-498311]: upstream data feeds

Hi Ken,

re: LDM logging not working
> "/etc/rpc" has been updated to replace spaces with tabs, however it did
> not appear to make a difference.  Do you have any ideas on the logging

The most likely causes for logging failure on Linux systems are:

- SELINUX is not turned off so the syslogd daemon is not allowed to write
  to a file in user space

- there is a syntax error in the syslogd configuration file /etc/syslog.conf

N.B.: /etc/rpc entries will have no affect on the ability of the system to
log using syslogd.

First thing to check:

- is SELINUX in force on your machine?

  To check this, first see if there is a /etc/selinux directory on your machine:

<as 'root'>
ls -alt /etc/selinux

- if your machine has SELINUX, verify that it is turned off:

<as 'root'>
cd /etc/selinux
cat config

-- if 'config' has a line that looks like:

SELINUX=enforcing

change it to:

SELINUX=disabled

After making such a change, your machine must be rebooted

Next, verify that the LDM entries added to /etc/syslog.conf are correct.  It
is the entries in /etc/syslog.conf that typically require tabs as whitespace
(it is operating system dependent whether spaces will work; tabs always work).

Two entries are required in /etc/syslog.conf; one will be an addition to
an existing line and the other will be new:

*.info;mail.none;news.none;authpriv.none;cron.none;local0.none          
/var/log/messages

#
# LDM
#
local0.debug                                        /local/ldm/logs/ldmd.log

NOTEs:

- the whitespace between local0.none and /var/log/messages should be tabs

- the whitespace between local0.debug and /local/ldm/logs/ldmd.log should be 
tabs

- the location of the LDM log file should be adjusted to match your LDM 
installation
  (i.e., your LDM log file may be /home/ldm/logs/ldmd.log; it may be 
/usr/local/ldm/logs/ldmd.log,
  etc.)

Once the necessary entries have been added to /etc/syslog.conf (by 'root'), you 
should
do the following:

<as 'ldm'>
cd ~ldm/logs
rm -f ldmd.log
touch ldmd.log
cd
hupsyslog
logger -p local0.debug 'test of LDM logging'

If everything is correct AND syslogd is running correctly (i.e., not wedged), 
then
you should end up with the test logging message in ~ldm/logs/ldmd.log.

As soon as logging is working, I would restart your LDM so you can see why you
are not receiving data from idd.cise-nsf.gov:

<as 'ldm'>
ldmadmin restart

> or lack of data coming in from idd.cise-nsf.gov?

We will learn the answer to this question as soon as we can see LDM log 
messages.

> Is it normal for the ldm processes to be in a "TIME_WAIT" state?

Yes and no.

Yes, processes go into a TIME_WAIT state when the exit.  If you
are reporting/attempting to report real time statistics (by having an 'exec'
of rtstats line in ~ldm/etc/ldmd.conf:

EXEC    "rtstats -h rtstats.unidata.ucar.edu"

then you would expect to see the statistics reporting process go into a 
TIME_WAIT
state after it sends statistics off to rtstats.unidata.ucar.edu.

No if the processes going into the TIME_WAIT state are the rpc.ldmd invocations
that are trying to receive data.  Again, the TIME_WAIT state shows that the
process exited for some reason (good or bad) and is waiting to be reaped by
the operating system.

> Thanks,

No worries.  We should be able to figure out why you are not receiving data
from idd.cise-nsf.gov as soon LDM logging is working.

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