|
Home > Archive > Unix Programming > August 2007 > Zombie Process :
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
|
|
|
| [nitin_k@appsdba childndemun]$ cat forkz.c
#include<stdio.h>
int main(){
if(fork()==0){
printf("%d\n",getpid());
}else{
printf("%d\n",getpid());
}
return 0;
}
this code after execution doesn not leave a zombie process .
The check being through
$ps -A| grep defunct
No processes where listed .
why ?
| |
|
| On Aug 20, 3:37 pm, Roy <royash...@gmail.com> wrote:
> [nitin_k@appsdba childndemun]$ cat forkz.c
> #include<stdio.h>
>
> int main(){
> if(fork()==0){
> printf("%d\n",getpid());
> }else{
> printf("%d\n",getpid());
> }
>
> return 0;
>
> }
>
> this code after execution doesn not leave a zombie process .
>
> The check being through
> $ps -A| grep defunct
> No processes where listed .
>
> why ?
As a special case, under Linux, if the parent explicitly ignores the
SIGCHLD (sets the handler to SIG_IGN, rather than simply ignoring the
signal by default), all child exit status information will be
discarded and no zombie processes will be left.
| |
| Ivan Gotovchits 2007-08-20, 7:52 am |
| Roy wrote:
> [nitin_k@appsdba childndemun]$ cat forkz.c
> #include<stdio.h>
>
> int main(){
> if(fork()==0){
> printf("%d\n",getpid());
> }else{
> printf("%d\n",getpid());
> }
>
> return 0;
> }
>
> this code after execution doesn not leave a zombie process .
>
> The check being through
> $ps -A| grep defunct
> No processes where listed .
>
> why ?
But why did it must be created? You returned from the main program, so any
child processes goes to the init processes and served by him.
| |
| Lew Pitcher 2007-08-20, 2:00 pm |
| On Aug 20, 6:37 am, Roy <royash...@gmail.com> wrote:
> [nitin_k@appsdba childndemun]$ cat forkz.c
> #include<stdio.h>
>
> int main(){
> if(fork()==0){
> printf("%d\n",getpid());
> }else{
> printf("%d\n",getpid());
> }
>
> return 0;
>
> }
>
> this code after execution doesn not leave a zombie process .
>
> The check being through
> $ps -A| grep defunct
> No processes where listed .
>
> why ?
With the code above, both the child and parent process terminate
almost immediately; neither has any code that would significantly
delay their termination. In this case, you have two possible
scheduling scenarios:
1) child terminates, then parent terminates, and
2) parent terminates, then child terminates
In scenario 1, as the parent is still running when the child
terminates, and the parent does not collect the child process' status,
the child process will be marked as a zombie process. Once the parent
process terminates, the child process' status will be reaped by init.
The interval between the child termination (when it becomes a zombie)
and the parent termination (when the child's status is reaped by init)
is likely to be extremely small. In this case, you /sometimes, if you
are lucky/ can time your commands such that a ps(1) will show the
child process in a zombie state. *But*, because that window is /very/
small, it is unlikely that you will be able to reproduce this display
very often, and for the most part, the child will /look/ like it never
became a zombie.
In scenario 2, as the parent has terminated while the child is still
running, init 'adopts' the child process. When the child process
terminates, init will reap the process status. Again, there is an
extremly small window between the child's termination and init's
collection of the status where a well-timed ps(1) will show the child
as a zombie. However, this window is even smaller than the window from
scenario 1, and is even more unlikely to be detected by random
executions of ps(1).
HTH
--
Lew
| |
| Al Balmer 2007-08-20, 2:00 pm |
| On Mon, 20 Aug 2007 04:21:25 -0700, nag <nagesh.20k@gmail.com> wrote:
>On Aug 20, 3:37 pm, Roy <royash...@gmail.com> wrote:
>
>
>
>As a special case, under Linux, if the parent explicitly ignores the
>SIGCHLD (sets the handler to SIG_IGN, rather than simply ignoring the
>signal by default), all child exit status information will be
>discarded and no zombie processes will be left.
Same for HP-UX. HP docs used to say that the child process's parent
was set to process 1, which harvested it. Current docs just say "If
the action for the SIGCHLD signal is set to SIG_IGN, child processes
of the calling processes will not be transformed into zombie processes
when they terminate."
--
Al Balmer
Sun City, AZ
| |
| David Schwartz 2007-08-20, 7:25 pm |
| On Aug 20, 3:37 am, Roy <royash...@gmail.com> wrote:
> this code after execution doesn not leave a zombie process .
How could it? (Hint: Ask yourself, if there was a zombie, who would be
its parent.)
DS
| |
|
| On Mon, 20 Aug 2007 15:05:10 -0700, David Schwartz wrote:
> On Aug 20, 3:37 am, Roy <royash...@gmail.com> wrote:
>
>
> How could it? (Hint: Ask yourself, if there was a zombie, who would be
> its parent.)
>
> DS
Off-topic: What's your name; who's your daddy.
["time of the seasons, IIRC]
By the zombies ;-)
Sorry. could not resist.
AvK
| |
| David Schwartz 2007-08-20, 7:25 pm |
| On Aug 20, 3:17 pm, moi <r...@localhost.localdomain> wrote:
> Off-topic: What's your name; who's your daddy.
> ["time of the seasons, IIRC]
> By the zombies ;-)
>
> Sorry. could not resist.
> AvK
Unix process semantics do get a bit gory. If a child's parent dies, it
is an orphan and is adopted. If it dies, the responsibility falls to
its parents to reap it lest it become a zombie. And so on.
DS
| |
|
| On Aug 21, 4:35 am, David Schwartz <dav...@webmaster.com> wrote:
> On Aug 20, 3:17 pm, moi <r...@localhost.localdomain> wrote:
>
>
>
> Unix process semantics do get a bit gory. If a child's parent dies, it
> is an orphan and is adopted. If it dies, the responsibility falls to
> its parents to reap it lest it become a zombie. And so on.
>
> DS
hi Lew , thanks for the excellent explanation .
#include<stdio.h>
int main(){
if(fork()==0){
printf("%d\n",getpid());
}else{
printf("%d\n",getpid());
sleep(4);
system("ps -A| grep defunct");
sleep(4);
}
return 0;
}
Output :
7060
7059
7060 pts/11 00:00:00 dem <defunct>
many thanks everybody ! :-)
|
|
|
|
|