SUMMARY: race condition: 'ps -o ppid -p $$' outputs ppid=1

Dan Astoorian and Darren Dunham both explained what's happening. Below
is Dan's reply. Also, William Hathaway noted that $PPID is another way
to obtain the parent process id under ksh. Thanks.

John

-----Original Message-----
From: Dan Astoorian [mailto:djast@cs.toronto.edu]
Sent: Thursday, May 13, 2004 2:06 PM
To: Spurgeon, John P
Subject: Re: race condition: 'ps -o ppid -p $$' outputs ppid=1


On Thu, 13 May 2004 16:47:11 EDT, "Spurgeon, John P" writes:
> I'm using Solaris 7 on IA and I've encountered a problem when trying
to
> use the ps command in a Korn shell script to obtain the parent process
> id of the executing process. I'm able to reproduce the problem using
the
> two test programs below (test-a and test-b). As the "typical test
> results" show, the ps command appears to suffer from some sort of race
> condition that causes it to occasionally output ppid 1 instead of the
> actual ppid. I'm running my programs on a server with 4 processors. I
> suspect that the problem is more likely to be encountered on a
> multi-processor system.
>
> Does anyone know what's going on here? Is this really a problem with
ps,
> or is there some other explanation? Does anyone know of another simple
> way to reliably determine the ppid from within a shell script?

ps is returning the correct results.

What's happening is that the parent process, having kicked off all the
jobs in the background as it was supposed to, has exited before some of
the children finished running.  (Did you notice the shell prompt in the
middle of Listing 3?)  Child processes whose parents have exited are
inherited by pid 1, and ps is (correctly) reporting this.

If you want the parent shell to wait for all the children to complete
before exiting, add the command "wait" after the for-loop in
/tmp/test-a.

Hope this helps,

--
Dan Astoorian               People shouldn't think that it's better to
have
Sysadmin, CSLab             loved and lost than never loved at all.
It's
djast@cs.toronto.edu        not, it's better to have loved and won.  All
www.cs.toronto.edu/~djast/  the other options really suck.    --Dan
Redican
_______________________________________________
sunmanagers mailing list
sunmanagers@sunmanagers.org
http://www.sunmanagers.org/mailman/listinfo/sunmanagers