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.
>From: Anthony Rockwood - MSCD Meteorology <address@hidden> >Organization: Metro State >Keywords: 199904091410.IAA13925 LDM queue problem core Tony- >Ok, it happened again last night. A big core file was created in >ldm/home/wxuser: > >-rw-r--r-- 1 wxuser staff 48391528 Apr 9 07:39 core. > >The command, 'file core' returned the following: > >core: ELF 32-bit LSB core file 80386 Version 1, from 'garp' Since this core file is from GARP, it does not indicate a problem with the LDM. However, if there was a huge core file, it could fill up your disk and then create some queue problems. By the time I looked, mcscour.sh had run, so you had plenty of disk space. The LDM looks like it is still running fine. Apparently, someone was running GARP this morning and it crashed at 7:39 am. You can go ahead and delete the core file. >The ldm is still running, but it may not for long. I won't delete the file >in case you want to look at it. If you're bogged down with the office >shuffle and can't look at this before the ldm quits, I'll just keep it >going as long as I can, but eventually I'll have to reboot. If you are worried about disk space, you could create a link in wxuser's home directory between core and /dev/null: ln -s /dev/null core so if GARP does crash, the output will go to the great bit bucket in the sky instead of writing to disk. The other option is to add: limit coredumpsize 0m to wxuser's .cshrc which limits the core size to 0 Mb. Either method will keep the core file from using up disk space. You might want to do the same for the user gempak. Can't get those new machines in here fast enough, eh? ;-) Don