UNIX for Dummies Questions & Answers

Hi all,

Am writing a ksh script where I am looking for processes that has gone defunct and all of which has the same PPID

PID is the variable that I need to match as this is the process ID of the processes that has gone defunct

Am just curious how come the following DOES NOT work?

Code:

ps -ef | grep "defunct" | grep -v grep | awk '{ print $3 }' | grep "^${PID}$"

I got it to work as below.

Code:

ps -ef | grep "defunct" | grep -v grep | awk '{ print $3 }' | grep "^`echo ${PID}`$"

I would have thought that the first command would have work or shouldn't it?

Due to {} brackets

Code:

$ps -ef | grep "defunct" | grep -v grep | awk '{ print $3 }' | grep "^`echo $PID`$"

It should - e.g. this works on ksh 93s+ (RHEL):

Code:

# ps
  PID TTY          TIME CMD
13088 pts/6    00:00:00 ps
20462 pts/6    00:00:00 ksh
# export PID=20462
# ps -ef | awk '{ print $3 }' | grep "^${PID}$"
20462
20462
20462

However, I'm a bit confused about what you're trying to do? All that will get you is a list of (the same) PPID - which you already know...

Depending on your system, you may be able to just do ps -ef $PID

If not, when you're using awk anyway, you might as well use awk to do the entire statement. You can do powerful things with very simple awk statements.

Code:

ps -ef | awk -v PID="$PID" '$3 == PID'

This should print the entire matching line.

There is much variation in the output format for "ps -ef" .

Please post what Operating System and version you have, the Shell (e.g. bash, ksh, sh etc.) and a sample of a few relevant lines from:

Code:

ps -ef|egrep "defunct|PID"|grep -v "grep"

The "egrep" for "PID" is just to get the column headings for this example and nothing to do with your variable called $PID.

I can't see anything wrong with the syntax of the first example you posted. Had you used the reserved variable name $PPID that would give trouble in many shells (notably bash).

The way your script behaves makes me wonder if your version of "ps", "awk" or Shell is changing the value of ${PID} (but not when it is a parameter to a sub-shell).

If you are on Solaris use "nawk" not "awk".

What are you actually trying to do?

Hi,

Thanks for your response. What am trying to do is looking for how many defunct processes are from an existing process ID.

We are using Oracle Enterprise Manager (OEM) which is an Oracle product used for monitoring Oracle databases. OEM uses what is called an agent. For some reason, when the agent starts, after a few days, some of the processes that it spawns becomes DEFUNCT when they shouldn't be. All these DEFUNCT processes has their PPID equal to the PID of the agent.

What am trying to do is write a script how many of such processes are DEFUNCT and if I have more than five (5) that means it is going to generate a file handles exhausted error in which case we have to re-start the agent.

Am wanting to grep using "^${PID}$" because sometimes there are some defunct process that are not spawned by the agent.

Example as below:

Code:

  oracle  2493  2277  0   Nov 27 ?       342:05 /opt/oracle/agent10g/bin/emagent

Checking for defunct processes related to the OEM Agent ...

  oracle  7668  2493  0                   0:00 <defunct>
  oracle  3537  2493  0                   0:00 <defunct>
  oracle 17004  2493  0                   0:00 <defunct>
  oracle  3470  2493  0                   0:00 <defunct>

Am trying to exclude defunct processes where PPID = 24935 or something similar which is why am wanting to make "^${PID}$" works. ${PID} is actually the PPID 'coz am using ps -ef | awk '{ print $3 }'

Hope it's clear what am trying to do.

---------- Post updated at 06:04 AM ---------- Previous update was at 05:58 AM ----------

Hi,

Thanks for your response. What am trying to do is looking for how many defunct processes are from an existing process ID.

We are using Oracle Enterprise Manager (OEM) which is an Oracle product used for monitoring Oracle databases. OEM uses what is called an agent. For some reason, when the agent starts, after a few days, some of the processes that it spawns becomes DEFUNCT when they shouldn't be. All these DEFUNCT processes has their PPID equal to the PID of the agent.

What am trying to do is write a script how many of such processes are DEFUNCT and if I have more than five (5) that means it is going to generate a file handles exhausted error in which case we have to re-start the agent.

Am wanting to grep using "^${PID}$" because sometimes there are some defunct process that are not spawned by the agent.

Example as below:

Code:

oracle  2493  2277  0   Nov 27 ?       342:05 /opt/oracle/agent10g/bin/emagent

Checking for defunct processes related to the OEM Agent ...

  oracle  7668  2493  0                   0:00 <defunct>
  oracle  3537  2493  0                   0:00 <defunct>
  oracle 17004  2493  0                   0:00 <defunct>
  oracle  3470  2493  0                   0:00 <defunct> 
  
Am trying to exclude defunct processes  where PPID = 24935 or something similar which is why am wanting to make  "^${PID}$" works. ${PID} is actually the PPID 'coz am using ps -ef |  awk '{ print $3 }'

BTW, didn't know there is a reserved variable named PPID.

Hope it's clear what am trying to do.

Please post what Operating System and version you have, the Shell (e.g. bash, ksh, sh etc.).

In most Shells $PPID is the PID of the process which invoked the current Shell. In bash Shell this environment variable is write protected.

Oracle needs substantial unix kernel tuning. The kernel parameter "maximum number of files open by any one user" is as important as "maximum number of files open on the system" and "maximum number of files locked on the system".
There are detailed kernel tuning guides from Oracle for each O/S, but there will still be more tuning depending on the application.

Getting "defunct" processes from an Oracle client-server application is nothing unusal and the Operating System should clear them up within an hour or so. They are commonly caused by people clicking "X" in a Windows client instead of doing a proper application logout. If they persist for longer this can be because of an application error or because they are stuck when accessing broken hardware.
Depending on your circumstances you may need to tune the unix kernel to allow for as many as double the Oracle clients you actually expect ... or more.