Re: zmailer kill scheduler

[Matti Aarnio <mea@nic.funet.fi>]

On Tue, Aug 31, 2004 at 02:53:51PM -0500, Roy Bixler wrote:
> On Tue, Aug 31, 2004 at 10:41:53PM +0300, Matti Aarnio wrote:
> > On Tue, Aug 31, 2004 at 01:44:30PM -0500, Roy Bixler wrote:
> > > I need a bit of guidance on the following, which is that if I execute
> > > "zmailer kill scheduler", I notice that there are still some remaining
> > > ZMailer scheduler processes running in attempts to deliver messages on
> > > the queue.  Does this sound right in general?  If so, does anyone have
> > > suggestions about the cleanest way to kill all scheduler processes?
> > 
> > With 'scheduler processes' I presume you do mean 'transport agents' ?
> 
> Yes.
> 
> > All transport agents are left behind, when the scheduler dies.
> > Most of them die immediately, some live a bit longer.
> > Eventually all will die.
> 
> Is there any sane way to make that occur immediately?  The scenario is
> that we are running ZMailer on a high availability cluster.  Fail over
> seems to be hampered sometimes and I suspect that the reason is that
> the transport agents are still running and consequently the shared
> disk partition can't be unmounted due to these processes still
> accessing it.

I guess they are 'smtp' programs ?  And your system is Solaris ?

Instant death is possible for them, too, but they are most likely
in 'dot-wait' (or connection setup, which should die instantly).
Death within smtp dot-wait will result in message to be double-delivered.

If you can accept that, then the protection domain can be eliminated.
In the   transports/smtp/smtp.c   you can find ONE instance of:
       dotmode = 1;
disable that (e.g. comment it out) and they all should die instantly.

> -- 
> Roy Bixler <rcb@ucp.uchicago.edu>
-- 
/Matti Aarnio	<mea@nic.funet.fi>
-
To unsubscribe from this list: send the line "unsubscribe zmailer" in
the body of a message to majordomo@nic.funet.fi