Re: [Mailman-Developers] CVS: mailman/Mailman ListAdmin.py,1.33,1.34
fil@orwell.bok.net said:
The actual current cron/crontab.in says the following: # Every 10 minutes retry failed deliveries. 02,12,22,32,42,52 * * * * / usr/bin/python /var/lib/mailman/cron/qrunner
It should be
# Every minute try pending deliveries. * * * * * /usr/bin/python /var/ lib/mailman/cron/qrunner
Could you check that its happy if there are overlapping queue runner jobs.
Also what happens if the MTA has been shut down? Things like this can be a real pain to deal with if you have to reboot a server and a last gasp cron job throws away mail because it fired up after the mta had stopped but before cron has been shut down... or various other scenarios.
Nigel.-- [ - Opinions expressed are personal and may not be shared by VData - ] [ Nigel Metheringham Nigel.Metheringham@VData.co.uk ] [ Phone: +44 1423 850000 Fax +44 1423 858866 ]
Whatever the bad situation is, it might happen as well with a 10-minutes cron frame as with a 1-minute. Except that the supposed "bug" will be noticed 10 times faster if it exists. So these questions are, in my view, not related to the cron-job frequency.
As an answer to your question, I've fired 3 parallel qrunner(s) and did not notice any problem (yet).
Fil.- Nigel Metheringham (Nigel.Metheringham@VData.co.uk) écrivait :
Could you check that its happy if there are overlapping queue runner jobs.
Also what happens if the MTA has been shut down? Things like this can be a real pain to deal with if you have to reboot a server and a last gasp cron job throws away mail because it fired up after the mta had stopped but before cron has been shut down... or various other scenarios.
"F" == Fil <fil@orwell.bok.net> writes:
F> It works great! Two cents=Cool!
F> * in order to still have a responsive server, you need qrunner
F> to be activated every minute or every other minute, not just
F> every half hour like it is now (usually).As you later noticed it runs every 10 minutes. I agree that it makes sense to run it more often. In fact, I think it should be running continuously but that's probably overkill for now. So let's try making it default to once per minute for now.
F> * nothing is logged into /logs/* when a message is
F> approved. Very stressfull for the mailman-master trying to
F> watch if it works. S/he has to think to look at qfiles/ to see
F> if the message was correctly processed.Good point.
"NM" == Nigel Metheringham <Nigel.Metheringham@VData.co.uk> writes:
NM> Could you check that its happy if there are overlapping queue
NM> runner jobs.qrunner should be safe; it first attempts to acquire a global lock but times out after 0.5 seconds. So if some other qrunner is running, it'll just log and exit.
NM> Also what happens if the MTA has been shut down? Things like
NM> this can be a real pain to deal with if you have to reboot a
NM> server and a last gasp cron job throws away mail because it
NM> fired up after the mta had stopped but before cron has been
NM> shut down... or various other scenarios.If the MTA is shut down, SMTPDirect.py should notice this and raise the exception that forces a re-queue of the message. Unless your MTA is down for 3 days, the message should be properly retried. One thing I realized: if MTA delivery fails and the message is dequeue, we need to potentially perform other modules in the message pipeline.
-Barry
On Wed, May 31, 2000 at 06:50:59AM -0400, Barry A. Warsaw wrote:
NM> Also what happens if the MTA has been shut down? Things like NM> this can be a real pain to deal with if you have to reboot a NM> server and a last gasp cron job throws away mail because it NM> fired up after the mta had stopped but before cron has been NM> shut down... or various other scenarios.
If the MTA is shut down, SMTPDirect.py should notice this and raise the exception that forces a re-queue of the message. Unless your MTA is down for 3 days, the message should be properly retried. One thing I realized: if MTA delivery fails and the message is dequeue, we need to potentially perform other modules in the message pipeline.
Actually, I read something else in this statement. We still use Sendmail (yeah yeah, I know :) and occasionally, mostly after receiving a lot of spam, there is so much mail in the queue that sendmail can't keep up with incoming mail, let alone catch up on the queue. So we stop sendmail and start a couple of queueruns, sometimes for some hours. I don't particularly like the idea of a qrunner starting every minute (or even every ten minutes) trying to send each and every mail in the queue... it strikes me as fairly wasteful :P
Then again, we currently use the Sendmail delivery module, so I'm not terribly worried or anything ;-P But perhaps it would be a good idea to catch some errors (like 'connection refused') and flag them like 'permanent' errors. But that isn't very straightforward in the current setup, methinks.
-- Thomas Wouters <thomas@xs4all.net>
Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
participants (4)
-
bwarsaw＠python.org -
Fil -
Nigel Metheringham -
Thomas Wouters