Trying to catch a parent process on a fast dying proces

[Craig A. Sharp]

I have a process that starts and I need to see what parent process is starting the child. I can see the child in ps -ef and get the pid but the parent/child dies so fast and restarts that when I catch the pid and try to grep for it, it is gone and the parent and child have restarted again. This happens ever few seconds.

I need to see the parent process.

Thanks

[Steven E. Protter]

Shalom Craig,

Use tusc to start the process.

It will collect good diagnostics.

http://hpux.cs.utah.edu/hppd/hpux/Sysadmin/tusc-7.8/

The depot:

usage

ouput=/tmp/tusc.txt
# set tusc equal to process id of the process that is parent.
/usr/contrib/bin/tusc -o $output -p $proc &


SEP

[A. Clay Stephenson]

Create a wrapper that is found earlier in the PATH than the "real" program and have it echo $PPID to a logfile and then exec the "real" program.

e.g.

Suppose that the errent process. is /usr/bin/myprog.

mv /usr/bin/myprog /usr/bin/myprog2
Create a wrapper shell, /usr/bin/myprrog

#!/usr/bin/sh

echo "${PPID}" >> /var/tmp/mylog
exec /usr/bin/myprog2 $@

[Craig A. Sharp]

Great ideas, but the problem is that we dont know which parent is starting the child process because the child and parent die before we are able to grep on the pid of the child.

[A. Clay Stephenson]

But you said that you know the child process. Given that, if you make the wrapper script the name of your child process then you should be good to go. In fact, if you rename the current child process, all the wrtapper script needs to do is echo it's ${PPID} and exit w/o even exec'ing the "real" program because all you want to know at this point is the parent process.

Your wrapper child process could even do something like this:

#!/usr/bin/sh

ps -p ${PPID} -f > /var/tmp/mylog
sleep 5
exit 0

and that would identify the parent process.

[James R. Ferguson]

Hi Craig:

Huh? "...I can see the child in ps -ef ...". Well, then you should be able to see the PID (of the parent).

Is the "parent" respawned from '/etc/inittab' ?

Regards!

...JRF...

[Craig A. Sharp]

I cant break out of the processes...they are in production so I need to find a way to do this live.

[Prashant Zanwar_4]

Check for lsof, it should have a way to know what are open processes ..

I have worked with ptree on solaris..
On HP You need to pretty much write your own loop..

/bin/ps -ef | awk -v v=$P1 ' ($3 == v) { print $2
} '

Check if this helps..

Thanks and regards
Prashant

[A. Clay Stephenson]

It could be perfectly normal for the processes to be spawning like this. It's not uncommon to fork(), exec() the child to something useful, and allow the parent to exit. At this point, I would do a bunch pf ps -ef's in a loop outputting to a file with a date command between each ps -ef. Sooner or later, you will get lucky and see both the parent and the child process but it soulds like what you really need is the parent's PPID.

[Bill Hassell]

And just a note about grep and ps. If you want to find a specific PID or PPID, use ps -fp ####, not grep. When you use grep, it takes a long time to type and will match all kinds of items on the line (grep knows nothing about the column with PID). ps knows how to locate process 100 times better than grep -- just check the ps man page.

How do you know the dying process exists? If it is by name, you can run ps from a script and have it find the exact name of the problem process when it occurs, then extract the PPID and have ps show the PPID -- all very fast when in a script. Here is an example that runs every second looking for a process named on the command line:

#!/usr/bin/sh
export PATH=/usr/bin
set -u

PROC=$1
while :
do
PSLINE=$(UNIX95=1 ps -C $PROC -o pid= -o ppid= -o args=)

if [ "$PSLINE" != "" ]
then
MYPPID=$(echo "$PSLINE" | awk '{print $2}')
echo "$PROC: $PSLINE"
echo " Parent is: $(ps -fp $MYPPID)"
sleep 1
fi

done

This code will handle only a single copy of the program. If multiple copies are found, only the first one is shown. Call this script findproc, make it executable and then run it. You can output the result into a logfile if the condition doesn't occur too often:

./findproc myProblemProg > /var/tmp/findproc.log

The above script makes use of a little used (but powerful) feature called XPG4 behavior. The -C and -o options are invalid unless the variable UNI95 is temporarily defined. -C produces an exact match for the process name (no grep here) and -o allows you to customize the columns that are listed. By adding a blank = to the end of the -o options, the header line is suppressed.

[rick jones]

Tusc was a good suggestion - not that you can tusc the child and see anything useful, but if you go one at a time tuscing various processes, having it follow forks, you should eventually come across the the one that is creating the short-lived parent of the short-lived child.

Other possibilities - there may be a way to enable auditing to see what you want.

The main parent may be tossing something into syslog.

Just a ps -ef to a file, if it happens to catch both the short-lived parent and the short-lived child should indeed also have the longer-lived grandparent process, and you could just walk back the list of ppids.

[Craig A. Sharp]

Got it...We were able to track down the actual program that was starting the parent process.

Thanks to all.