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 Bob, re: > I received the message below from Chris Godfrey. Chris G: Sorry I didn't > see your message till this morning. > > I came in this morning and when I ran a ps to check for LDM processes I > found: > > ldm 5500 0.1 0.1 39036 10208 ? S 07:52 0:00 > decoders/dcgrib2 -d data/gempak/logs/dcgrib2_RUC.log -e > GEMTBL=/home/gempak/NAWIPS/gempak/tables > > ldm 7350 0.2 0.3 67648 31516 ? S 08:00 0:00 > decoders/dcisig -e GEMTBL=/home/gempak/NAWIPS/gempak/tables -d > data/gempak/logs/dcisig.log data/gempak/isig/YYYYMMDDHH_isig.gem ... One would expect to see multiple GEMPAK decodes running given the setup in the LDM pattern action file that is being used, ~ldm/etc/pqact.conf. re: > I was curious what would happen if I stopped LDM and restarted. I did, with > a "ldmadmin scour", again I saw these errors when I ran the scour: > > (blizzard) /local/ldm > ldmadmin scour > > /local/ldm/ldm-6.13.6/bin/scour: line 119: cd: ~ldm/data/gempak/acft: No > such file or directory > > scour: directory ~ldm/data/gempak/acft does not exist, skipping > > /local/ldm/ldm-6.13.6/bin/scour: line 119: cd: ~ldm/data/gempak/airm: No > such file or directory > > scour: directory ~ldm/data/gempak/airm does not exist, skipping ... This is very strange. When I was logged in yesterday, and in my current login, I see all of the various GEMPAK data directories under ~ldm/data. I would suspect that there was a problem with the mounted file system, but 'mount' shows that the disk is local: (blizzard) /local/ldm > mount ... /dev/mapper/vg_atms2-data2 on /data type ext4 (rw,noatime) re: > When I restarted, it seemed to be fine though. I'm surprised about the > above errors though. Me too. The LDM would have nothing to do with directories not being found. re: > Looking at the processes I see after the stop/start: > > # ps gaxu |grep -e ^USER -e ^ldm > > USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND > > ldm 8869 0.0 0.0 21828 1768 ? Ss 08:05 0:00 ldmd -I > 0.0.0.0 -P 388 -M 256 -m 354 -o 354 -q /local/ldm/var/queues/ldm.pq > /local/ldm/etc/ldmd.conf ... re: > I don't believe there are "hung" processes. Tom, am I correct? You are correct. While the LDM is running, processes (e.g., decoders) run by the LDM utility 'pqact' will show up in the process list as will at least one 'ldmd' process (there will be one 'ldmd' for each upstream REQUEST and downstream feed that are active along with the lead 'ldmd' process). Other than the very strange instances of the ~ldm/data/gempak/... not being found, I don't see a problem. Am I missing something? 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: ROJ-852250 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.