NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
So just for fun yesterday I disabled the cleanup script, just to see what would happen. What happened was that the computer froze like always, onlythis time I didn't have the runaway "gf" process.
Locally the computer was responsive enough that I was able to get it to reboot cleanly, however unresponsive enough that even given 2 full hours it was unable to open a terminal When I rebooted I got an error with rtstats, but wasn't quick enough to actually get the exact error. I logged the top command, and it shows a few things: 1) The logfile continued well after twister became unresponsive twister stopped responding around 4:45, the logfile continues until 7:45 (when I rebooted) 2) Nothing is very taxing to the system 3) The only running process is the ldm Upon reboot the ldm product queue was corrupt. I've attached the top logfile in case someone has a better idea how to interpret then I do On 10 May 2005, Steve Chiswell wrote:
Gabe, If you run cleanup while a script is running, you will kill the gplt process and orphan the gf process. When you remove the message queue (the script does this with the "ipcrm -q" command), you nolonger have a connection to the gf process.The script should be run when your scripts are not running. Another bit of advice is to run each script in its own temporary directory (such as shown in the csh examples using $$ to obtain a unique process id for a working directory name) so you don't have multiple scripts creating race conditions with ipcs and .nts files. Steve Chiswell Unidata User Support
gembud
archives: