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

[LDM #WDB-706909]: Restarting LDM



Hi Martha,

re:
> I have added the ldmadmin pqactHUP to the script which runs ldmadmin
> scour. And I don't think the issue is the ldmd.log; I am using "ldmadmin
> newlog" once per day  to handle that.

I agree that it is unlikely that your rotation of the LDM log files is
related to the problems you are seeing.

> I will check the pqact files for "-close" with the FILE directives.

In my opinion, this is the most likely place for the problem.

> The issue may be that I am going overkill on the deletions. As Tom knows
> we have recently increased greatly the amount of data we are collecting,
> both via our in-house noaaport ingestor and from several types of
> CONDUIT data.  One problem I have had involved BUFR files, as we were
> suddenly generating so many that xcdscour was failing because of the
> LINUX OS being unable to handle the large number of files with the "rm"
> command.    I ended up running xcdscour for BUFR files every three
> hours, which may be too much.  I have cut it back to every 6 hours
> to try to fix the other issue with phantom disk space.

I don't think that the scouring of BUFR or GRIB/GRIB2 files is the cause
of your problem.  Or, at least, not for those being processed into
the MySQL database for McIDAS use.  The reason I say this is that none
of these files are held open for writing.  The problem you are seeing is
most likely being caused by the deletion of a file that is open for
writing.  In short, we've been there and done that, so we are in tune
with the situation :-).

> Also, the GRInnnnn files were being deleted in two different places. I
> have corrected this to 1 script, using qrtmdg.k GRID 50001 64000

Did you write another script to delete the GRIDnnnn files?  This is one
of the things that mcscour.sh was written to do.

> I know we have had issues also because of our mixed mode
> installation (basically UNIDATA but with SSEC artifacts) so is it still
> okay to use both mcscour.sh and ldmadmin scour?

I _strongly_ recommend that the LDM scouring utility ('scour' which can be
run as 'ldmadmin scour' and is configured through ~ldm/etc/scour.conf) _not_
scour the directories that are populated with McIDAS decoding output.  Given
this, I recommend again that you review the contents of your 'scour' 
configuration
(again, ~ldm/etc/scour.conf) and comment out the entries that scour directories
that are handled by mcscour.sh and xcdscour.

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: WDB-706909
Department: Support LDM
Priority: Normal
Status: Closed


NOTE: All email exchanges with Unidata User Support are recorded in the Unidata inquiry tracking system and then made publicly available through the web. If you do not want to have your interactions made available in this way, you must let us know in each email you send to us.