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 Phil, re: > Thank you - I still haven’t yet had a chance to really dig into the issue, > but I’m > attaching a link to a tarball of our ldmd.conf and our log files (if you’d > prefer that I > attach it, just let me know). I didn't see anything that jumped out as me as being problematic in the various files included in the compressed tarball you provided. I did note, however, that the pattern-action files referenced in the /home/ldm/etc/ldmd.conf file were not included in the compressed tarball: #EXEC "pqact" exec "pqact -f ANY-NNEXRAD-CRAFT-NIMAGE etc/pqact.gempak_decoders" exec "pqact -f WMO etc/pqact.gempak_nwx" exec "pqact -f MCIDAS|NIMAGE etc/pqact.gempak_images" exec "pqact -f NNEXRAD|WSI|FNEXRAD|EXP etc/pqact.gempak_nexrad" exec "pqact -f CRAFT etc/pqact.gempak_craft" Can you provide these files? re: > I’m still convinced that something is eating system > resources on Saturday morning, but I haven’t been able to track it down of > yet. A couple of things would be useful: - the LDM registry file: ~ldm/etc/registry.xml - listing of all processes running in 'ldm's cron This may tell us if 'ldm'-initiated processes are part of the problem you are experiencing. - the output from 'ldmadmin config' - some information on the machine you are using: - output of 'uname -a' - output of 'cat /proc/cpuinfo' and 'cat /proc/meminfo' - output of 'df -h' - output of 'mount' - a long list of your GEMPAK log file directory The typical setups for GEMPAK output are either: ~ldm/data/gempak OR ~ldm/var/data/gempak Exactly where your GEMPAK output directory can be found is a function of how your LDM is setup in the ~ldm/etc/registry.xml file and how the actions are defined in the GEMPAK pattern-action files. Again, your tarball did not include any of these files. What I am really looking for is a long list of the GEMPAK logs directory. Please see below for further comment... re: > ldmd.log.1 was Sunday > ldmd.log.2-6 were from Saturday, > ldmd.log.7 was Friday > > http://twister.sbs.ohio-state.edu/unidata/ldmd-2014-10-13-1252.tar.gz I did not see anything untoward in your LDM log files. re: > I’ll try to take a closer look at everything this afternoon and implement > some of the > suggestions that others provided to see if I can resolve the issue. One thing I have found on numerous user systems is the failure to rotate GEMPAK decoder log files. The net result of this especially on 64-bit systems is HUGE decoder log files. Cleaning them up (i.e., properly rotating them) has solved performance problems on more than one users's machines. re: > Thanks again! No worries. 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: ZQD-728782 Department: Support IDD Priority: Normal Status: Closed