Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 20 Jan 2005 05:25:28 -0500 (EST)
From:      Tom Huppi <thuppi@huppi.com>
To:        spam maps <spamrefuse@yahoo.com>
Cc:        freebsd-stable@freebsd.org
Subject:   Re: User's cron job creates zombie process on 5.3
Message-ID:  <Pine.BSF.4.58.0501200510140.50418@nuumen.pair.com>
In-Reply-To: <20050120100638.88174.qmail@web54002.mail.yahoo.com>
References:  <20050120100638.88174.qmail@web54002.mail.yahoo.com>

next in thread | previous in thread | raw e-mail | index | archive | help

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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.58.0501200510140.50418>