User's cron job creates zombie process on 5.3

[Tom Huppi]

On Thu, 20 Jan 2005, spam maps wrote:

> Peter Jeremy wrote:
> > On Wed, 2005-Jan-19 21:14:26 -0800, spam maps wrote:
> >
> >>>	( /usr/bin/ssh -n -f ${tunnel} & )
> >>
> >>Alas, no success. Still get the <defunct> zombie
> >>process.
> >>
> >>I actually wonder if this is an odd or buggy
> >>behaviour of ssh, or is cron making a mistake here?
> >
> >
> > The cron daemon (which will have a PPID of 1) forks
> > a copy of itself to actually handle the cron job
> > (I suspect this is the parent of the zombie that
> > you are seeing).  This child process runs
> > "/bin/sh -c CRONJOB" (where CRONJOB is the line in
> > your crontab) and I suspect this is the zombie you
> > are seeing.
> >
> > My guess is that your ssh process is holding open
> > file descriptors and the cron child process is
> > waiting for these descriptors to close before
> > wait()ing for the child.  If this is true, then you
> > should avoid it with something like:
> >  ( /usr/bin/ssh -n -f ${tunnel} >/dev/null 2>&1 & )
> >
>
> BINGO!
> That works. Zombie has gone. Thank you.
>
> >>Leaving a zombie process around, means there's a
> kind
> >>of bug/mistake somewhere, right?
> >
> > Yes.  But it's not necessarily a bug in FreeBSD :-).
>
> So, after you've given me a complicated solution to
> avoid the zombie, can you tell which program is at
> error here? Cron, ssh, or FreeBSD?

There are two other possibilities I could thing of off hand;
Bourne Shell, or indeed, the 'program' (albeit a small one) which
you wrote!  My vote would be the latter.  I vote that way because
a change in the code (based on a good knowledge of the mechanics
of the language and unix in general) made the problem go away.
It's mainly a matter of perspective I guess :)

Thanks,

 - Tom