Re: rc.sendmail
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. John 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 FreeBSD.org 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 startup: /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. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. 26 The Paddocks Savill Way PGP: http://www.infracaninophile.co.uk/pgpkey Marlow Tel: +44 1628 476614 Bucks., SL7 1TH UK ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: rc.sendmail
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 FreeBSD.org 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 > startup: > > /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. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. 26 The Paddocks Savill Way PGP: http://www.infracaninophile.co.uk/pgpkey Marlow Tel: +44 1628 476614 Bucks., SL7 1TH UK pgp0.pgp Description: PGP signature
Re: rc.sendmail
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) 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 startup: /usr/sbin/sendmail -L sm-mta -bd -q1h /usr/sbin/sendmail -L sm-mqueue -qp5m /usr/sbin/sendmail -L sm-clientmqueue -Ac -qp5m 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? John On Saturday, June 21, 2003, at 10:53 PM, Makoto Matsushita wrote: john> Could someone please explain rc.sendmail to me? Is rc.sendmail(8) not enough for you? -- - Makoto `MAR' Matsushita ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: rc.sendmail
[Dropped [EMAIL PROTECTED] from the CC -- this is definitely [EMAIL PROTECTED] material] On Sat, Jun 21, 2003 at 05:33:49PM -0400, John Von Essen wrote: > Could someone please explain rc.sendmail to me? I am unclear why it > does what it does. I currently have everything enabled in rc.conf: > > mta_start_script="/etc/rc.sendmail" > sendmail_enable="YES" > (1) sendmail_flags="-L sm-mta -bd -q30m" > sendmail_submit_enable="YES" > (2) sendmail_submit_flags="-L sm-mta -bd -q30m > -ODaemonPortOptions=Addr=localhost" > sendmail_outbound_enable="YES" > (3) sendmail_outbound_flags="-L sm-queue -q30m" > sendmail_msp_queue_enable="YES" > (4) sendmail_msp_queue_flags="-L sm-msp-queue -Ac -q30m" > > With the above settings, when I do a 'make start', only (1) and (4) get > started. If I set sendmail_enable="NO", then only (2) and (4) start. If > I set sendmail_enable="NO" and sendmail_submit="NO", then only (3) and > (4). > > This doesn't make any sense to me. For starters, why would I ever want > just (3) and (4) running? Furthermore, I can't seem to get (1), (3), > and (4) to all start together. I imagine people would want those three > since you need your main sendmail running, and you could have a need > for an "always-on" queue runner for mqueue and clientmqueue. Anyhow, here are a couple of answers I prepared earlier, which you might find useful: http://groups.google.co.uk/groups?selm=20020906085719.GC34657%40happy-idiot-talk.infracaninophi.lucky.freebsd.questions&oe=UTF-8&output=gplain http://groups.google.co.uk/groups?selm=aupkof%24ki2%241%40FreeBSD.csie.NCTU.edu.tw&oe=UTF-8&output=gplain Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. 26 The Paddocks Savill Way PGP: http://www.infracaninophile.co.uk/pgpkey Marlow Tel: +44 1628 476614 Bucks., SL7 1TH UK pgp0.pgp Description: PGP signature
rc.sendmail
Could someone please explain rc.sendmail to me? I am unclear why it does what it does. I currently have everything enabled in rc.conf: mta_start_script="/etc/rc.sendmail" sendmail_enable="YES" (1) sendmail_flags="-L sm-mta -bd -q30m" sendmail_submit_enable="YES" (2) sendmail_submit_flags="-L sm-mta -bd -q30m -ODaemonPortOptions=Addr=localhost" sendmail_outbound_enable="YES" (3) sendmail_outbound_flags="-L sm-queue -q30m" sendmail_msp_queue_enable="YES" (4) sendmail_msp_queue_flags="-L sm-msp-queue -Ac -q30m" With the above settings, when I do a 'make start', only (1) and (4) get started. If I set sendmail_enable="NO", then only (2) and (4) start. If I set sendmail_enable="NO" and sendmail_submit="NO", then only (3) and (4). This doesn't make any sense to me. For starters, why would I ever want just (3) and (4) running? Furthermore, I can't seem to get (1), (3), and (4) to all start together. I imagine people would want those three since you need your main sendmail running, and you could have a need for an "always-on" queue runner for mqueue and clientmqueue. Thanks. John ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"