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

Re: 20010126: LDM logfiles and server access

Hi Erick,

Sounds like one of those days!

By default, the ldm uses the syslog daemon for logging. In your case, it's
the syslog daemon that was continuing to write to that file even after you
renamed it. To get it write to the new ldmd.log file it needs to receive a
HUP signal.  This signal tells the daemon to reread it's configuration
file.

What's supposed to happen when the logs are rotated is that ldmd.log is
moved to ldmd.log.1, a new zero length ldmd.log file is created, then the
syslog daemon is hup'ed by calling the ldm program 'hupsyslog'.

But, if you restarted the ldm with an empty ldmd.log file in place and
nothing happened, then you've moved beyond this problem to a possibly more
fundamental one.  

Here are the pieces that you need for ldm logging to work:

- You need one and only one syslog daemon running.  Check this with 
        'ps -ef | grep syslogd'.

- There must be a line in /etc/syslog.conf that tells the syslog daemon to
write messages from local0 of level debug or greater to the
/usr/local/ldm/logs/ldmd.log (or where ever you keep your logs).  Confirm
that a line like this is in the file:
        local0.debug /laraine/ldm/logs/ldmd.log 
(Use tabs between fields - sometimes it won't like spaces.)

- The file /usr/local/ldm/logs/ldmd.log must exist. (Hence the need to
create the zero length file mentioned above.)
 
- wThe ldm program 'hupsyslog' must be setuid root, i.e., its
permissions
must be like this:
-rwsr-xr-x   1 root     ustaff     24041 Dec  5 13:31 hupsyslog*

So, check that the above components are in place.

Regarding not receiving data, the command
        notifyme -vl - -h typhoon.atmost.ucla.edu 
will show you two things.  If typhoon has an 'allow' line for your machine
in it's configuration, which is what you need so that it will relay data
to you, then it will show you all the data that is arriving there.

If your syslog daemon got bolluxed up, and something else changed causing
you to stop receiving data, it sounds possible that you might be having
some system problems.  Has anyone checked the system log? (usually in
/var/adm/messages)

Anne
***************************************************
Anne Wilson                     UCAR Unidata Program            
address@hidden                 P.O. Box 3000
                                  Boulder, CO  80307
----------------------------------------------------
Unidata WWW server       http://www.unidata.ucar.edu/
****************************************************

On Fri, 26 Jan 2001, Unidata Support wrote:

> 
> ------- Forwarded Message
> 
> >To: address@hidden
> >From: Erick Lorenz <address@hidden>
> >Subject: LDM logfiles and server access
> >Organization: UCAR/Unidata
> >Keywords: 200101262249.f0QMnRX23103
> 
> I have been running and old installation of ldm (5.0.6) on a machine that
> had been retired from that duty (a SGI Indy running Irix 5.3) to tide us
> over until I could get Linux reinstalled on the host that is supposed to be
> the LDM server (it was invaded).  The Indy's LDM is just processing text
> data such as FOS.
> 
> This morning it was appearent that it had stopped collecting data.  I
> thought it might have to do with the power outage at UIUC but I also
> noticed that the log file was showed:
> 
> Jan 26 20:01:01 5Q:atm23 typhoon[22134]: run_requester: 20010126190101.349
> TS_ENDT {{DDPLUS,  ".*"}}
> Jan 26 20:01:01 3Q:atm23 typhoon[22134]: FEEDME(typhoon.atmos.ucla.edu): 7:
> Access denied by remote server
> Jan 26 20:01:31 5Q:atm23 typhoon[22134]: run_requester: 20010126190131.423
> TS_ENDT {{DDPLUS,  ".*"}}
> Jan 26 20:01:31 3Q:atm23 typhoon[22134]: FEEDME(typhoon.atmos.ucla.edu): 7:
> Access denied by remote server
> Jan 26 20:02:01 5Q:atm23 typhoon[22134]: run_requester: 20010126190201.496
> TS_ENDT {{DDPLUS,  ".*"}}
> Jan 26 20:02:01 3Q:atm23 typhoon[22134]: FEEDME(typhoon.atmos.ucla.edu): 7:
> Access denied by remote server
> 
> I contacted the manager at UCLA, James Murakami, who assured me that they
> were getting data.  He also added the numerical IP address of ATM23 to his
> file in case the verbal one was not working.
> 
> I tried again to start the LDM with no luck and then did something which
> has made it even more difficult to see what is going on.  I noticed that
> the log file "ldmd.log" was 0 bytes while the file ldmd.log.1 was getting
> larger.  I tried to correct this by moving ldmd.log and the four old log
> files (ldmd.log.1 to .4) to a subdirctory for archiving and created new log
> files with touch.
> When I restarted the LDM it still would not write to the log files as
> defined in ldmadmin.
> 
> I found that it was still writing to the archived file ldmd.log.1 in the
> subdirectory.  It is as if the ldm is remembering the inode of the last
> file it wrote to and is not paying attention to the file name.  I then
> copied the archived logfiles to another disk and deleted them.  Since then
> I have not been able to get the LDM to write to any log file.  I have:
> 
>   tried changing the name of the default file in ldmadmin.  
> 
>   tried starting the LDM with and without an empty ldmd.log file in place.  
> 
>   tried various permutations of the "ldmadmin newlog" command. 
> 
>   checked the ownership and permissions of the entire path to the log file.
> 
> In the mean time the LDM seems to start ok but when I do ldmadmin watch I
> see no incoming files so I assume that it is still being denied.  
> 
> My most urgent question is how to get the LDM to recognize and write
> messages to its defined log file.
> 
> Thanks
> 
> Erick Lorenz
> U C Davis
> 
> 
>   +--------------------------------------------------------------------------+
>   | Erick Lorenz, Programmer/Analyst                     Voice: 530-752-8297 |
>   | Atmospheric Science                                  FAX:   530-752-1552 |
>   | Land, Air & Water Resources                                              |
>   | University of California, Davis            e-mail:  address@hidden |
>   +--------------------------------------------------------------------------+
> 
> 
> ------- End of Forwarded Message
> 
>