GEMPAK Site Administrator's Guide

Originally Prepared by Ron Miller

This document covers a few topics that are important for anyone using GEMPAK. In general, GEMPAK requires very little maintenance once it is properly installed. Primarily, the tasks fall into two categories: patching and cleaning.

Software Patches

GEMPAK is an extremely large and complex software package. The source code, executable code, and other system files occupy about 75 Megabytes of disk space. With such a large package, bugs are inevitable. As these bugs are discovered and fixed or as enhancements become available, software patches will be necessary. Rather than re-installing the entire package, patches containing only the affected files will occasionally be released which will overwrite the existing files. The installation of a software patch will be similar to the initial installation, which is basically un-taring a file or tape.

Cleanup

Whenever a GEMPAK graphics program is run, the application starts a graphics Unix process (gplt), and gplt starts a device driver Unix process (wx, ps, nc, etc). These Unix processes communicate with each other through a method known as message queues. When a user is finished running GEMPAK, he/she must run the program GPEND. The GPEND program will close the message queues and remove the gplt and device driver processes. If the user neglects to run gpend, the gplt and device drive processes as well as the message queues remain active. Since there are a finite number of message queues available, repeated offenses could result in the system running out of available message queues.

In addition to simply forgetting to run GPEND, users will also cause orphaned processes and message queues if the ctrl-C to abort a GEMPAK program or close a GEMPAK graphics window using the pull-down menu on the upper-left widget. Thus, it is important to periodically check for orphaned processes by using the Unix /bin/ps command for all processes, piped into the grep command for gplt. Here is an example:

%/bin/ps -ef | grep gplt
rmiller 7871 7802 2 15:27:27 ttyp7 0:00 grep gplt
rmiller 3024 3027 0 17:12:39 ? 0:00 gplt

If you find any processes that have been orphaned, remove them with a kill command:

%kill 3024

where the 3024 is the process id returned by the /bin/ps command. (Note that the first number in the above example is the process id). Be careful that the gplt process you are about to kill is really an orphaned process and not one that is in use in another workspace or by another user.

To check for orphaned message queues, run the interprocesses communication status (ipcs) command:

     %ipcs

     IPC status from /dev/kmem as of Wed Oct 19 15:32:23 1994
     T     ID     KEY        MODE       OWNER    GROUP
     Message Queues:
     q      3 0x000a1187 -R---------    root      root
     q     54 0x0d5dcf71 --rw-rw-rw-    root      root
     q    305 0x47441905 -Rrw-rw-rw-    rmiller   csdg
     q    256 0x44441905 --rw-rw-rw-    rmiller   csdg
     q     57 0x4744190a --rw-rw-rw-    rmiller   csdg
     Shared Memory:
     Semaphores:

To remove an orphaned message queue, use the ipc remove (ipcrm) command:

%ipcrm -q 305

where 305 is the queue number returned by the ipcs command. Again, make sure that the message queue is truly orphaned before removing it. NOTE: you must remove the gplt and device driver processes before removing the message queues.

To help with this cleanup process, there is a script in the $NAWIPS/bin directory called cleanup. It automatically removes all gplt processes and message queues associated with your user-id. This is a convenient script, but can also be dangerous as it may remove processes or message queues that were still in use. So, make sure that you really want to clean up everything before running cleanup.