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 Carol, Steve, Mike and I just finished discussing the situation that you ran into on typhoon... very strange indeed, and something that we have never seen before. The following is more "for the files" than anything else: - the problem encountered was an ldmd process trying to write a new product into the LDM queue but being able to do so because all of the products in the queue were locked The 6.13.6 ldmd process exited when it was unable to write the product, and the LDM kept running. Steve assured us that this was valid behavior. - we (I) recommended increasing the LDM queue size from 500M to 8G, but noted that this was to keep in line with the recommendation that about an hour be kept in the local queue This recommendation allows the LDM to do better duplicate product detection and elimination. NB: we do NOT think that using a 500M queue was the cause of the problem seen! - the only scenario that makes any sense to us given the symptoms we see represented by LDM log file messages is that somehow the 500M queue got corrupted, and this was manifested in locks on products in the queue not being released The creation of a new queue, 8G in your case, should have remedied the problem in the 500M queue if there was one. Your reporting that you ran into the same problem sometime around 15:46 yesterday afternoon _after_ making a new, 8G queue, does not support the guesstimate that the problem was a corrupted queue. Question: - is it possible that the ordering of making a new queue was different than what you reported? I.e., is it possible that the LDM was restarted while the existing 500M queue was still being used, and the problem was run into again at more or less 15:46? We ask this since we are trying to reconcile the LDM restarts we see reflected in the LDM log files in ~ldm/var/logs. Closing comment: - the LDM registry entry for <datadir-path> in the <pqact> section is currently: /usr/local/ldm/var/data <datadir-path> will be the current working directory for 'pqact' invocations. This why the log file for the 'grbfile.sh' process is located in /usr/local/ldm/var/data/logs given that the log file specified in the ~ldm/etc/pqact_satellite.conf pattern-action file is the relative 'logs/grbfile.log'. If you want the log files for the 'grbfile.sh' process to be put in the same directory as the LDM log files, ~ldm/var/logs, you will need to either change the <datadir-path> directory to /usr/local/ldm/var, or change the values specified in pqact_satellite.conf. I find it most useful if all of the LDM related log files are located in the same directory, so I recommend modifying either the actions in pqact_satellite.conf or changing <datadir-path> in the LDM registry. NB: if you change definitions in the LDM registry, the LDM will need to be restarted for the change(s) to become active. 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: OMZ-874415 Department: Support IDD 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.