Re: [Exim] 1.000.000 email delivered in single session

Página superior
Eliminar este mensaje
Responder a este mensaje
Autor: Philip Hazel
Fecha:  
A: Sheldon Hearn
Cc: exim-users
Asunto: Re: [Exim] 1.000.000 email delivered in single session
On Fri, 2 Nov 2001, Sheldon Hearn wrote:

> It looks like exim doesn't reap children until piped input stops. Right
> now, my 'exim -bS -odqs' process is stuck in piperd state, and the
> injector won't continue because all the exim children that routed and
> queued messages thus far are in zombie state!


Hmm. On looking at the code, I find I was wrong. This isn't supposed to
happen. This is an extract from exim.c:

--------------------------------------------------------------------
/* Loop for several messages when reading SMTP input. Reset the pool store
each time. If we fork any child processes, we don't want to wait for them
unless synchronous delivery is requested, so set SIGCHLD to SIG_IGN in that
case. This is not the same as SIG_DFL, despite the fact that documentation
often lists the default as "ignore". At least on some systems, setting SIG_IGN
causes child processes that complete simply to go away without ever becoming
defunct. You can't therefore wait for them - but we don't want to wait for them
in the non-synchronous delivery case. */

if (!synchronous_delivery) signal(SIGCHLD, SIG_IGN);
--------------------------------------------------------------------

You aren't setting -odi or -odf by mistake, are you?
If not, I suppose you could try this patch

--------------------------------------------------------------------
*** exim-3.33/src/exim.c    Wed Aug 15 12:09:09 2001
--- exim.c    Fri Nov  2 13:45:54 2001
***************
*** 3462,3467 ****
--- 3464,3470 ----
      }


    /* The loop will repeat if more is TRUE. */
+   while (waitpid(-1, NULL, WNOHANG) > 0);
    }


exim_exit(EXIT_SUCCESS); /* Never returns */
--------------------------------------------------------------------

It does an explicit reap for any completed processes after each message
submission, but it isn't *right* because the processes may complete
later, while your process is waiting. I don't propose to put this into
the source tree. At least, not yet - until you let me know if it has any
effect.



-- 
Philip Hazel            University of Cambridge Computing Service,
ph10@???      Cambridge, England. Phone: +44 1223 334714.