The problem with depending on sendmail -bd -q30m to clean out /var/spool/mqueue is that it is slow! This is why I want to run a separate Persistent Queue runner for mqueue.

In my case I have a fallback mx server which gets all the "bad" email (undeliverable, slow recipient, etc.,.). The problem is sometimes the fallback is under heavy load, and mail to the fallback gets queued on my slave nodes. The mail has to get off the slave nodes quickly, this is why I want a persistent queue runner for mqueue and clientmqueue.

The fallback machine is doing the standard -bd -q1h and -Ac -q1h, which works fine.

Obviously this all comes down to preference. In my case I WANT a listening daemon, mqueue runner, and clientmqueue runner. I am surprised that rc.sendmail wont grant my request. In the end, I will simply re-code rc.sendmail to do what I want. But again, I dont understand the harm of having rc.sendmail behave the way I want it to behave. If I select sendmail_outbound_enable="YES" - what is the harm is doing what I ask - why does rc.sendmail have to get in my way.


On Sunday, June 22, 2003, at 04:14 AM, Matthew Seaman wrote:

On Sat, Jun 21, 2003 at 11:50:21PM -0400, John Von Essen wrote:
Okay, before people send more responses... Yes, I have looked at man
rc.sendmail and I do understand how everything works. My question is
WHY was it designed to behave they way it does?

Why isn't rc.sendmail setup such that you can start the listening
daemon for inbound, queue runner for outbound, and the msp queue
runner. (Currently, you cant start that config with rc.conf and
rc.sendmail due to rc.sendmail's logic)

You seem to be under the misconception that running sendmail with the '-bd' flag so that it listens on port 25 for incoming messages somehow negates the '-q15m' flag that tells it to scan and process the mail queue every fifteen minutes. ie. you don't need separate sm-mta and sm-queue processes for those functions, as the sm-mta will do both.

If your site handles a sufficient volume of e-mail that running
separate listener and queue flushing daemons would be advantageous,
then I'd recommend looking at an alternative MTA: one of exim, postfix
or qmail should be appropriate -- the mail system pumps
out enormous amounts of mailing list traffic using postfix.

Obviously, you can't run the localhost submission daemon AND the port
25 remote daemon listening for inbound. For that case, it is either one
or the other - so that part of rc.sendmail makes sense. But if I select
"YES" to enable both the mqueue runner and the clientmqueue runner in
rc.conf, the rc.sendmail script will not perform this. The logic of
rc.sendmail will only start mqueue if sendmail and sendmail submit are
set to "NO". Likewise, if you select sendmail "YES", then the only
other thing you can run is the clientmqueue runner.

In my case, I need to run the sendmail daemon, the mqueue runner, and
the clientmqueue runner. In other words, I need the following at

/usr/sbin/sendmail -L sm-mta -bd -q1h
/usr/sbin/sendmail -L sm-mqueue -qp5m

Why not just run:

/usr/sbin/sendmail -L sm-mta -bd -q5m ?

The overhead of sendmail forking a child every five minutes is trivial.

/usr/sbin/sendmail -L sm-clientmqueue -Ac -qp5m

I'm not sure either why you want to flush the queue quite so frequently. Sendmail will attempt to deliver any new message immediately. It's only if the other side can't receive the message straight away that the messagegets stuck into the queue. Any message held in this way should stay queued for a sufficient time to allow the other end a chance to clear whatever problem it was causing the hold-up.

rc.conf and rc.sendmail cannot startup what I want. As a result, I have
to do sendmail_enable="NONE", and then from rc.local startup what I
want manually.

Why can't rc.sendmail be designed such that whatever has "YES" in
rc.conf will get started?

If you think you can do it better, please do submit patches.



Dr Matthew J Seaman MA, D.Phil. 26 The Paddocks
Savill Way
PGP: Marlow
Tel: +44 1628 476614 Bucks., SL7 1TH UK

_______________________________________________ [EMAIL PROTECTED] mailing list To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Reply via email to