Originally Posted by malati desai
yah..I got your point..and I am working on it..
but I have some more questions in my mind..
1. waitpid waits for processes which are in parent-child relationship.
but other than that ,can a process wait for any processes which are
not in parent-child relationship?
Can process wait for any process?How to do that?
Nope. waitpid is for waiting for one out of many child processes. If you supply an arbitrary pid you will get an ECHILD error return if the supplied pid is not a child of the process using the waitpid system call.
That is why processes are reparented - init cannot receive any signals from any process other than its direct children. Reparenting allows those signals (specifically SIGCHLD) to be received.
2.suppose I have pid of X process?
how to get all child processes of that X process..even if X process get exited ,how to get information (like pid) of its child processes..?
You don't. While the X process exists it is possible to search all processes that exist that have the X process as its parent - but once X exits, all child processes get reparented - by default, the parent becomes init. The problem is that such searches are asynchronous which permits losing references... pstree is an attempt to capture a snapshot of the process table (it isn't perfect as it is also asynchronous, but does try to reduce the window for failures) then sorts the data to create the process tree.
An example of when this fails is during fork bombs. It is also why you have trouble killing them. It is possible - but you have to make the priority of the process doing the search higher than any other process, AND never introduce a wait (which destroys the snapshot). The easiest way I found to stop a fork bomb has been to reduce the priority of all pids running the fork bomb. It took me 10 to 15 tries before the new pids running the fork bomb were all at a low priority (fortunately for me, I wasn't on a cluster at the time). THEN it was possible to kill them faster than they could spawn. (Even so - it is still possible for them to get away from you, but a "killall -u" on the users login eventually nails them all. It also helps to have some large memory CPU bound jobs to help force them into delays).
It is for this reason that the prctl system call was extended to setting what pid would be designated to be used when reparenting. This is the ONLY way that can sucessfully accomplish what you want.