This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.
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