Getting rid of a <defunct> process

Wonderly gregg at ihlpb.ATT.COM
Tue Feb 14 01:51:50 AEST 1989


>From article <102 at avatar.UUCP>, by kory at avatar.UUCP (Kory Hamzeh):
> I have written an application which forks and execs off many subtasks.
> The main process (the parent which does all of the forks) can not
> do a wait() because I can't get blocked for anything. Well, this results
> in a lot of "<defunct>" processes in the process table when the child
> exits.
> 
> Is there any way to get rid of these processes? If not, will they take
> up any core space? I assume they will take up a slot in the process table.

If you have SIGCLD, you have two choices.  If you absolutly do not wish to
know anything about the children than just use

    signal (SIGCLD, SIG_IGN);

to tell the kernel to implicilty wait on them for you.  When they die, they
will be removed...  If you wish to know something, then use something like

    routine ()
    {
        int status, pid;

        while ((pid = wait (&status)) == -1 && errno == EINTR)
            continue;
        if (status)
            printf ("Process %d died with status 0x%04x\n", pid, status);
    }

    main (...)
    {
    ...
        signal (SIGCLD , routine);
    ...
    }

to look at the return status and catch possible problems.  I would suggest
that you do check return status because subtle problems can go unnoticed if
you do not.

If you do not have SIGCLD, use

    junk()
    {}
        
    main()
    {
    ...
        try_wait();
    ...
    }

    try_wait()
    {
        int amt, status, pid, (*ftn)();

        amt = alarm (0);
        ftn = signal (SIGLARM, junk);
        (void) alarm (1);

        pid = wait (&status);
        (void) alarm (0);

        (void) signal (SIGALRM, ftn);
        (void) alarm (amt);

        if (pid != -1 && status)
            printf ("Process %d died with status 0x%04x\n", pid, status);
    ...
    }
-- 
Gregg Wonderly                             DOMAIN: gregg at ihlpb.att.com
AT&T Bell Laboratories                     UUCP:   att!ihlpb!gregg



More information about the Comp.unix.questions mailing list