20000405: file system full on Lyndon State Debian Linux running McIDAS-XCD (fwd)

===============================================================================
Robb Kambic                                Unidata Program Center
Software Engineer III                      Univ. Corp for Atmospheric Research
address@hidden             WWW: http://www.unidata.ucar.edu/
===============================================================================

---------- Forwarded message ----------
Date: Wed, 05 Apr 2000 10:20:23 -0600
From: Tom Yoksas <address@hidden>
To: Mark Tucker <address@hidden>
Subject: 20000405: file system full on Lyndon State Debian Linux running
    McIDAS-XCD

>From: Mark Tucker <address@hidden>
>Organization: Lyndon State College
>Keywords: 200004051409.IAA17096 McIDAS-XCD LDM startxcd xcd_run

Mark,

re: file system filling related to LDM
>I've had a similar problem on our ldm system (ldm 5.0.8, Linux 2.0.36).
>All I've been able to figure out is that the growth occurs somewhere in
>the ~mcidas directory.  Likewise, our data is written to a separate file
>system which is not affected when this occurs.  Restarting the ldm
>always seems to fix this problem which, thankfully, does not happen very
>often.

The two LDM-related files that are typically written to the ~mcidas
directory hierarchy on machines running Unidata McIDAS-X and -XCD are
ROUTEPP.LOG and XCD_START.LOG.  ROUTEPP.LOG is appended to and closed
by McIDAS ROUTE PostProcess BATCH files kicked off by ingestion of
imagery in the Unidata-Wisconsin datastream.  Since these updates do
not keep the log file open, it is possible to scour the file whenever it
is not being written (through cron, for example).

XCD_START.LOG is opened and written to by the XCD supervisor routine,
startxcd.k which, in turn, is run from the Bourne shell script, xcd_run
which is run at LDM startup through an ldmd.conf 'exec' entry.
XCD_START.LOG does not get closed until startxcd.k exits, and
startxcd.k should not exit until the LDM is stopped.  It is only at
this point that the log file can be deleted successfully (this is done
for you at LDM (re)start by code in xcd_run).  Some sites have
unadvisedly implemented scouring of XCD_START.LOG through a cron entry
in the hopes that the file size will be kept at a minimum.  Are you one
of them?  Such cron-initiated scouring of XCD_START.LOG will not work
as desired, however, since the file will not be closed when the
scouring occurs so it will not get truncated.

If your problem is really related to XCD_START.LOG growing appreciably,
the question is why this is happening?  The only scenario that I can
imagine is one where one or more XCD data monitor processes (e.g.,
DMISFC, DMRAOB, DMSYN, DMMISC, or DMGRID) is continually exiting and
being restarted.  Each time a data monitor routine is (re)started an
entry is written in XCD_START.LOG.  If you are seeing this sort of
continual (re)start, the solution is to find out what is failing and
implement a fix.  On a system that is running with no LDM restarts,
XCD_START.LOG should remain very small.  Here at the UPC for example,
XCD_START.LOG is only 1348 bytes long after the LDM and XCD processes
have been functioning continuously for just over a week!

Tom
--
+-----------------------------------------------------------------------------+
* Tom Yoksas                                             UCAR Unidata Program *
* (303) 497-8642 (last resort)                                  P.O. Box 3000 *
* address@hidden                                   Boulder, CO 80307 *
* Unidata WWW Service                             http://www.unidata.ucar.edu/*
+-----------------------------------------------------------------------------+