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.
Gabe, The _gf programs don't spawn a gplt or gf process because they are liniked together in a single executable, and as a result, the "gf" you have can absolutely not be from one of those scripts. Since you have a gf process, you must have run a program that isn't a _gf version, and so you must have gpend at the end of those. Steve Chiswell Unidata User Support On Mon, 2005-05-09 at 09:55, Gabe Langbauer wrote: > Steve, > > There are several scripts that don't use gpend...I talked with Chris > Hennon, who wrote most of these scripts and he states "I use the program > sfmap_gf (instead of sfmap) to > create the gif files. Programs that end in "_gf" do not spawn a gplt > process, so you do not need to use 'gpend' to terminate it. Those > programs were created to make the scripts cleaner and run faster." > > If that isn't true, I'll go ahead and put 'gpend' at the end of the > scripts > > Is it possible that the cleanup script is somehow interacting with a gf > process that it shouldn't be? It appears that the 'gf' process that is > causing the trouble is always the one that is called following the cleanup > script on the crontab. > > On 4 May 2005, Steve Chiswell wrote: > > > Gabe, > > > > The program "gf" is the GEMPAK X-window based gif driver. This is not > > a cleanup script. > > > > If you have "gf" processes as well as "gplt" processes hanging around, > > then either: > > 1) You are not running "gpend" to shut down the message queue and > > device driver. > > 2) Your cron or other program that is producing gifs is crashing > > before getting to the "gpend" command. > > > > The "cleanup" script in the gempak distribution will remove old message > > queues, and gplt processes associated with such problems, but if the > > problems are frequent, then you need to look at what scripts etc you > > have that are being run to generate the problem. > > > > Since the "gf" driver uses an X server, you must have an X server > > available to connect to using the DISPLAY environmental variable. > > Verify that you aren't having problems related to that. If you are > > running crons, then typically you would be running a virtual X server > > (xvfb) to use to generate displays, or use the "gif" DEVICE in your > > script which does not use the X server. > > > > Steve Chiswell > > Unidata User SUpport > > > > > > > > On Wed, 2005-05-04 at 09:38, Gabe Langbauer wrote: > > > Steve, > > > > > > You may remember me asking about our crashing system here at Ohio State a > > > few weeks ago...I've coninued to monitor the situation and it appears that > > > what is occuring is that the cleanup script "hangs" and takes up 99% of > > > the cpu for hours on end, until the whole system just crashes. > > > > > > I'm only guessing that it's the cleanup script, the command name is "gf" > > > which could be anything...but the time it is occuring seems to relate with > > > the time the cleanup script should be running. I even changed the cron > > > time of the cleanup script to test, and the time of the crashes changed > > > accordingly. > > > > > > Is there any "fixes" to the cleanup script that I may be missing? Is > > > there any reason you can think of that the cleanup script may hang like > > > this? Any other thoughts? > > > > > > My system has the following characteristics: > > > Dell Xeon dual-processors with RedHat v. 3 > > > Gempak 5.7.3 > > > > > > Any help would be greatly appreciated! > > > > > > Thanks, > > > > > > Gabe Langbauer > >