20031204: no ldmd.log files

>From: "Molenar, Deb" <address@hidden>
>Organization: CSU/CIRA
>Keywords: 200312041801.hB4I1dp2019245 LDM log files clock drift

Hi Deb,

Long time no see (this is Tom).

First, can you tell me the name of the system you are working on.
I see the following machines running LDM 6.x at CSU and reporting
real time statistics:

luna.cira.colostate.edu [ 6.0.13 ]
sunset.atmos.colostate.edu [ 6.0.14 ]

>Hi.  I'm working to bring up 6.1.3 on a linux box.

There is no LDM 6.1.3.  Do you mean 6.0.3?  If yes, please do not use
this distribution.  Instead, upgrade the LDM to the latest Unidata
release, LDM 6.0.14.  There were a lot of important changes made in the
LDM between 6.0.3 and 6.0.14.

If you meant 6.1.13, then upgrading is not absolutely necessary, but
it is still advisable.

>Data ingest seems to be
>working fine, but I am not getting any log files.  The error message when I
>type ldmadmin start is:
>
>hupsyslog:  kill -HUP 772:  Permission denied

This tells me that the installation of the LDM was not complete.  The
step that is missing is most likely the 'make' invocation that must be
done as root:

<login as 'root'>
cd ~ldm/ldm-6.0.14/src
make install_setuids

This step changes the owner and permissions on the 'hupsyslog' and
'rpc.ldmd' executables in ~ldm/ldm-6.0.14/bin.  While the LDM can run
without this step, we _strongly_ recommend that you perform it.  The
main reason for this is that if the step is not performed, the LDM will
not use port 388 for its transfers.  Instead, it will use the port
mapper to assign a port.  This can result in problems especially with
firewall configurations.

>so the process appears to be unable to restart syslogd.  I've checked all
>permissions, and made sure the entry in /etc/syslog.conf is correct;  is
>there anything else I need to check?

It may well be the case that the ownership and permissions on
'hupsyslog' and 'rpc.ldmd' are not your only problems.  I would double
check to make sure that you have correctly setup entries in
/etc/syslog.conf as 'root'.  While you are at it, double check the
entries in /etc/rpc and /etc/services (note that white spaces are
tabs in the following examples!):

/etc/rpc:

ldm     300029  ldm

/etc/services:

ldm     388/tcp         unidata         # Unidata LDM

/etc/syslog.conf   <- entries here will vary depending on OS type,
                      here is an example for RedHat Linux:

 ...

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

#
# LDM messages on local0
#
local0.debug                            /usr/local/ldm/logs/ldmd.log


You will need to adjust the syslog.conf entries to match your system
setup.  For instance, if your LDM log files are in /data/ldm/logs, the
last entry would look like:


local0.debug                            /data/ldm/logs/ldmd.log

etc.

After making the change to /etc/syslogd.conf as 'root', send a HUP
signal to the process ID of syslogd:

ps -ax | grep syslogd
kill -HUP <pid of syslogd>

Next, test to make sure that you can put log entries in your log
file.  Do this as the user running your LDM (typically 'ldm'):

<as 'ldm'>
<make sure that ~ldm/logs/ldmd.log is owned by 'ldm'>

logger -p local0.debug 'test of LDM logging'

You should see the message 'test of LDM logging' written to your LDM
log file if everything was done correctly.  If this does not work,
go back to the entries you made in syslog.conf and look for typos.

While we are on the subject, if you are working on, or in charge of
sunset.atmos.colostate.edu, then you should be aware that the clock
on that machine is not being set often enough.  A good illustration
of this can be found in the latency plot of the IDS|DDPLUS data feed:

http://www.unidata.ucar.edu/cgi-bin/rtstats/iddstats_nc?IDS|DDPLUS+sunset.atmos.colostate.edu

The sawtooth pattern for the latencies indicates that the clock is
being set once per day at 6 Z.  It then drifts for the rest of the day
reaching a difference of about 30 seconds.  If you are setting the
clock through a cron-initiated 'ntpdate' invocation, I would suggest
increasing the frequence at which it is run to 4 times per hour.  Here
is an example entry:

0,15,30,45 * * * * /usr/sbin/ntpdate timeserver.colostate.edu > /dev/null

This example assumes that there is a timeserver named
timeserver.colostate.edu.  You should adjust the entry to match what is
available.

From the limited number of real time stats reports from luna, it is
difficult to see if it also has a clock drift problem.

Please let me know how your logging problem turns out, and if it
is really you that should be contacted about the clock drift problem
on sunset.

Cheers,

Tom

>From address@hidden Thu Dec  4 16:45:09 2003

Thanks for the feedback.  I am running 6.0.13 on luna.  I'll forward
your time set request to Natalie Marquez who manages sunset.

Got my logging bug worked out -- thank you.  The key was setting
ownership of bin/hupsyslog & bin/rpc.ldmd.  For some reason that did
not get done when I installed 6.0.13.  I will upgrade as soon as
possible -- right now I'm trying to get rid of the system (scorpio)
that is still running 5.0.8!

Take care.