Very Computer

I don't seem to have any problem killing the child, but after several
iterations I run out of process space and I can no longer fork().
Could someone please shed some light on what I'm doing wrong.  Mild
flames are tolerable if I'm doing something REALLY stupid :-)

Using: Sun sparc 2, 4.1.1
Code follows:
----------------------------------------
#include <stdio.h>    /* this is main() and fun() */
#include <signal.h>

int fun();

main()
{
    int pid;

    while (1) {
        pid = fun();
        sleep(1);
        if ((kill(pid,SIGKILL)) == -1) {
            fprintf (stderr,"Kill failed\n");
            exit(1);
        }
    }

Quote:}

    switch(pid = fork()) {
        case -1:
            fprintf (stderr,"Can't fork\n");
            break;
        case 0:
            execl("./tst","tst",(char *)NULL);
            fprintf (stderr,"Can't exec\n");
            break;
        default:
            return pid;
    }

Quote:}

main()
{
    puts ("in tst");
    while (1)
        ;

Quote:}

Dave Farnham
Ball Aerospace
Electro-Optical/Cryogenics Division
P.O. Box 1062
Boulder, CO  80306

Quote:

>    while (1) {
>        pid = fun();
>        sleep(1);
>        if ((kill(pid,SIGKILL)) == -1) {
>            fprintf (stderr,"Kill failed\n");
>            exit(1);
>        }

Quote:>     }

                        -Kartik

--
internet% ypwhich

|> >I'm having trouble getting rid of processes which I've killed.
|> >I have a situation where the main program calls a function which
|> >fork()'s and exec()'s.  This function returns the pid of the
|> >child to the main program.  The main program then kill()'s this child.
|> >
|> >I don't seem to have any problem killing the child, but after several
|> >iterations I run out of process space and I can no longer fork().
|> >Could someone please shed some light on what I'm doing wrong.  Mild
|> >flames are tolerable if I'm doing something REALLY stupid :-)
|>
|> Most likely, the reason why you're running out of process space is because
|> you don't wait() for your children. You can kill your children 'till you're
|> blue in the face, and it won't help any. That's because when a process
|> dies, it becomes a zombie until someone waits for it. This means that it
|> takes up a space in the process table, though it's really not doing
|> anything. It's a simple fix:
|>
|> >
|> >    while (1) {
|> >        pid = fun();
|> >        sleep(1);
|> >        if ((kill(pid,SIGKILL)) == -1) {
|> >            fprintf (stderr,"Kill failed\n");
|> >            exit(1);
|> >        }
|>            wait(0); /* add this line in */
|> >       }

Is this all that's wrong with vi in SunOS??? Doing:

vi
!}fmt
:r!ps

produces (extras left out):

  PID TT STAT  TIME COMMAND
 4262 p5 S     0:00 vi
 4263 p5 Z     0:00 <defunct>
                    ^^^^^^^^^
With one of these for each shell run from within vi. Gets anoying when your
process table gets full...

In good old original UNIX, the only way to get rid of a zombie was to
wait() on it, and if its parent terminated, then init (Process #1) would
inherit it and IT would wait() on it.

  You need to wait on your children to get them to go away; until you do that,
they're zombies.

  Here's my occasionally posted article about that:

  Unfortunately, it's impossible to generalize how the death of child
processes should behave, because the exact mechanism varies over the
various flavors of Unix.  Perhaps someone who's "in the know" (or at
least more so than I am) about POSIX can tell us what the POSIX standard
behavior (if there is any) for this is.

  First of all, by default, you have to do a wait() for child processes
under ALL flavors of Unix.  That is, there is no flavor of Unix that I
know of that will automatically flush child processes that exit, even if
you don't do anything to tell it to do so.

  Second, allegedly, under some SysV-derived systems, if you do
"signal(SIGCHLD, SIG_IGN)", then child processes will be cleaned up
automatically, with no further effort in your part.  However, people
have told me that they've never seen this actually work; the best way to
find out if it works at your site is to try it, although if you are
trying to write portable code, it's a bad idea to rely on this in any case.

  If you can't use SIG_IGN to force automatic clean-up, then you've got
to write a signal handler to do it.  It isn't easy at all to write a
signal handler that does things right on all flavors of Unix, because of
the following inconsistencies:

  On some flavors of Unix, the SIGCHLD signal handler is called if one
*or more* children have died.  This means that if your signal handler
only does one wait() call, then it won't clean up all of the children.
Fortunately, I believe that all Unix flavors for which this is the case
have available to the programmer the wait3() call, which allows the
WNOHANG option to check whether or not there are any children waiting to
be cleaned up.  Therefore, on any system that has wait3(), your signal
handler should call wait3() over and over again with the WNOHANG option
until there are no children left to clean up.

  On SysV-derived systems, SIGCHLD signals are regenerated if there are
child processes still waiting to be cleaned up after you exit the
SIGCHLD signal handler.  Therefore, it's safe on most SysV systems to
assume when the signal handler gets called that you only have to clean
up one signal, and assume that the handler will get called again if
there are more to clean up after it exits.

  On older systems, signal handlers are automatically reset to SIG_DFL
when the signal handler gets called.  On such systems, you have to put
"signal(SIGCHILD, catcher_func)" (where "catcher_func" is the name of
the handler function) as the first thing in the signal handler, so that
it gets reset.  Unfortunately, there is a race condition which may cause
you to get a SIGCHLD signal and have it ignored between the time your
handler gets called and the time you reset the signal.  Fortunately,
newer implementations of signal() don't reset the handler to SIG_DFL
when the handler function is called.

  The summary of all this is that on systems that have wait3(), you
should use that and your signal handler should loop, and on systems that
don't, you should have one call to wait() per invocation of the signal
handler.  Also, if you want to be 100% safe, the first thing your
handler should do is reset the handler for SIGCHLD, even though it isn't
necessary to do this on most systems nowadays.

--
Jonathan Kamens                               USnail:
MIT Project Athena                              11 Ashford Terrace

Office: 617-253-8085                          Home: 617-782-0710

Quote:> You need to wait on your children to get them to go away; until you
> do that, they're zombies.
>   Here's my occasionally posted article about that:
> Unfortunately, it's impossible to generalize how the death of child
> processes should behave, because the exact mechanism varies over the
> various flavors of Unix.  [...]

This way, the parent has no children left, because its only child
exited.  When the intermediate process died, init (PID 1) inherited the
second child and will worry about doing the wait() when it dies.

Not that this is always appropriate, but sometimes it is.

                                        der Mouse

                        old: mcgill-vision!mouse