Good morning all,
Over the years, I have noticed various shell operations on my LDM system
slow down. I just sort of assumed it was getting old like me! This
morning I decided to resolve why ldm user shell logins were taking 10-20
seconds to happen.
After debugging the login, I discovered thousands of .tmp_netcdf.* files
in the ldm user's home directory. I asked my friend Google what it
thought of this and ran into this thread:
https://www.unidata.ucar.edu/support/help/MailArchives/ldm-mcidas/msg00489.html
Which pointed a finger at GEMPAK's dcncprof, but the thread appeared to go
silent. My LDM system runs GEMPAK 6.6.0, so I diffed the difference in
dcncprof.c between that version and 7.0.4
181c181
< tempnam = (char *)malloc(32);
---
tempnam = (char *)malloc(19);
183,184c183,184
< sprintf(tempnam,".tmp_dcncprof_netcdf.XXXXXX\0");
< mktemp(tempnam);
---
sprintf(tempnam,".tmp_netcdf.XXXXXX\0");
mkstemp(tempnam);
192c192
< outfilnam = (char *)malloc(strlen(ofil)+33);
---
outfilnam = (char *)malloc(strlen(ofil)+20);
216d215
< close(outfilnam);
So the differences are mktemp vs mkstemp and that's the bug. mkstemp
returns an open file descriptor that is never closed nor deleted. strace
shows the fun too:
open(".tmp_netcdf.Bm67hk", O_RDWR|O_CREAT|O_EXCL, 0600) = 4
open("/data/gempak/profiler/.tmp_netcdf.Bm67hk", O_WRONLY|O_CREAT|O_TRUNC,
0644) = 5
So moral of the story, look for lots of .tmp_netcdf.* files in your LDM's
home directory and upgrade GEMPAK :)
PS: This command may be useful to you if you have so many files that
rm .tmp_netcdf.*
fails.
find . -name '.tmp_netcdf.*' -exec rm {} \
daryl
--
/**
* Daryl Herzmann
* Assistant Scientist -- Iowa Environmental Mesonet
* http://mesonet.agron.iastate.edu
*/
