[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

19990126: ps command hangs under GEMPAK accounts

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.

  • Subject: 19990126: ps command hangs under GEMPAK accounts
  • Date: Wed, 27 Jan 1999 08:48:14 -0700
>From: "Robert R. Mullenax" <address@hidden>
>Organization: National Scientific Balloon Facility
>Keywords: 199901270124.SAA26057 Gemenviron ps PATH

Hi Robert-

>I don't know if this has anything at all to do with GEMPAK
>or any Unidata software, but after running GEMPAK a lot
>recently I find that the ps command hangs, in other words I type
>ps  or ps -eaf and nothing happens.  I have to hit cntrl-C
>and then use ipcrm to remove a message queue that is created.
>This only happens under users which I have been using GEMPAK,
>user gempak and user weather, which also runs McIDAS.
>I have source Gemenviron in my .cshrc and I setenv GEMDATA
>in each Gemenviron. Do you have any ideas where I loused things
>up.  I am running Solaris 7 for Intel and GEMPAK 5.4.  By the way,
>Solaris 7 has a CDE app called Find Process that displays
>an output equivalent to ps + some flags and that works fine.
>
>The ps from the command line works fine from other accounts,
>root, ldm, and mcidas.

Unfortunately, ps is the name of the PostScript driver in GEMPAK
which conflicts with the system ps command.  Apparently, your
path is searching the $GEMEXE directory and finding GEMPAK's ps
before the system ps (/bin/ps).  That is why you are finding
GEMPAK processes started when you run ps.

In the Gemenviron script, $GEMEXE (directory for GEMPAK executables)
is put into they PATH by:

#
#
# Set PATH to include $GEMEXE
#
setenv SCRIPTS_EXE   $NAWIPS/bin/scripts
setenv PATH ${PATH}:${GEMEXE}:${SCRIPTS_EXE}

So, if in your .cshrc file, /bin is not in the PATH before Gemenviron
is sourced, then you could have the ps conflict.

I have the sourcing of Gemenviron as the last thing in my .cshrc
so all my paths are set first and then $GEMEXE is appended.

This is one of those things that should be put in a FAQ if 
we had one. ;-)

Don Murray