Hi,
I'm running the latest cvs (just updated again this morning just to be sure) but their doesn't seem to be any more posts being send out on the list?? they all arrive on the approval page, but once approved they vanish into nothing... I'm not sure how long this has been going on though... anybody else having the same trouble?
Ricardo.
--
"RK" == Ricardo Kustner <ricardo@rixhq.nu> writes:
RK> I'm running the latest cvs (just updated again this morning
RK> just to be sure) but their doesn't seem to be any more posts
RK> being send out on the list?? they all arrive on the approval
RK> page, but once approved they vanish into nothing... I'm not
RK> sure how long this has been going on though... anybody else
RK> having the same trouble?Take a look in the qfiles directory. Do you see a bunch of files with really long names and extensions .msg and .db? You must reload the crontab.in file to get all the new cron scripts running at the right intervals. Of primary importance is qrunner which clears the messages waiting in qfiles.
This is documented in the UPGRADING file, which I know no one will read. Be prepared to answer this question over and over again. ;)
-Barry
On Thu, Jun 29, 2000 at 02:45:23AM -0400, Barry A. Warsaw wrote:
"RK" == Ricardo Kustner <ricardo@rixhq.nu> writes: RK> I'm running the latest cvs (just updated again this morning RK> just to be sure) but their doesn't seem to be any more posts RK> being send out on the list?? they all arrive on the approval RK> page, but once approved they vanish into nothing... I'm not RK> sure how long this has been going on though... anybody else RK> having the same trouble? Take a look in the qfiles directory. Do you see a bunch of files with really long names and extensions .msg and .db?
no it's empty unfortunately...
You must reload the crontab.in file to get all the new cron scripts running at the right intervals.
i've already fallen in that trap earlier ;) about a month ago my digests weren't send out for a few days... but since then I've been doing a crontab update with every cvs upgrade...
Ricardo.
-- International Janet Jackson fanclub called MISS JANET. For more information write to: Miss Janet. P.O.Box 10016, 1001 EA Amsterdam, The Netherlands Fax/phone: +31-(0)20-7764493 Email: fanclub@miss-janet.com Or check out our website: http://miss-janet.com
On Thu, 29 Jun 2000, Barry A. Warsaw wrote:
"RK" == Ricardo Kustner <ricardo@rixhq.nu> writes:
RK> I'm running the latest cvs (just updated again this morning RK> just to be sure) but their doesn't seem to be any more posts RK> being send out on the list?? they all arrive on the approval RK> page, but once approved they vanish into nothing... I'm not RK> sure how long this has been going on though... anybody else RK> having the same trouble?Take a look in the qfiles directory. Do you see a bunch of files with really long names and extensions .msg and .db? You must reload the crontab.in file to get all the new cron scripts running at the right intervals. Of primary importance is qrunner which clears the messages waiting in qfiles.
This is documented in the UPGRADING file, which I know no one will read. Be prepared to answer this question over and over again. ;)
Does this mean that message delivery is not handled at all when the incoming mail is passed to mailman, and every message needs to wait for a cronjob to run ? I found the method used in 1.1 (try to deliver immediatelly, if it fails, the cronjob will handle it) much more appropriate, even though it often resulted in mail duplication (if the mail was handled the same time when the cronjob was run, it was sometimes delivered by both methods), which could have been fixed by some better locking mechanisom...
-- Madarasz Gergely gorgo@caesar.elte.hu gorgo@linux.rulez.org It's practically impossible to look at a penguin and feel angry. Egy pingvinre gyakorlatilag lehetetlen haragosan nezni. HuLUG: http://mlf.linux.rulez.org/
"GM" == Gergely Madarasz <gorgo@caesar.elte.hu> writes:
GM> Does this mean that message delivery is not handled at all
GM> when the incoming mail is passed to mailman, and every message
GM> needs to wait for a cronjob to run ?Yes. The reasons for the change are manyfold, but all are based on my primary goal for 2.0 - delivery reliability. By that I mean, no messages should ever get lost, if they are deliverable at all, and no duplicates should ever be sent.
In 2.0 we're stuck with the lack of a database with transactions, necessitating the use of lockfiles. This means that there is a significant chance that messages can be delivered to the `post' script, but cannot be delivered because the list lock could not be acquired. If Mailman didn't queue the message, it could get bitbucketed. Other situations could cause the message to be not-completely-delivered within the command time limit that some MTAs (e.g. Postfix) have.
It turns out that queuing the message immediately is a huge boon to debugging too, because I can now inspect messages before they've gone out.
The penalty for the improved reliability is 1) there's more disk I/O; 2) messages get held for up to 1 minute + the time it takes qrunner to reach the message during its loop.
I think both are acceptable give then benefits.
-Barry
Hi,
On Mon, 10 Jul 2000 14:12:21 -0400 (EDT), Barry A. Warsaw said:
GM> Does this mean that message delivery is not handled at all GM> when the incoming mail is passed to mailman, and every message GM> needs to wait for a cronjob to run ?Yes. The reasons for the change are manyfold, but all are based on my primary goal for 2.0 - delivery reliability. By that I mean, no messages should ever get lost, if they are deliverable at all, and no duplicates should ever be sent. It turns out that queuing the message immediately is a huge boon to debugging too, because I can now inspect messages before they've gone out.
yeah i agree... I really like the new queuing method... if you turn off the qrunner from the crontab you can easily debug the process step by step... this also makes it easier to understand the way Mailman's Handlers and message pipeline works.
Ricardo.
-----Original Message----- GM> Does this mean that message delivery is not handled at all GM> when the incoming mail is passed to mailman, and every message GM> needs to wait for a cronjob to run ?
Yes. The reasons for the change are manyfold, but all are based on my primary goal for 2.0 - delivery reliability. By that I mean, no messages should ever get lost, if they are deliverable at all, and no duplicates should ever be sent.
unfortunately, this still seems to be the case. I have a 2.0beta3 (with newlist patch) installation with which I sent a single mail to a list I created. I myself received only one copy of the mail, but there were several people who received a varying number of copies, from 4 to 12 (!). Can you or someone tell me how this could happen? and where should I look to try to debug the problem. I could understand if everyone was getting the same number of duplicates, but this is not the case.
Robert
participants (6)
-
"Ricardo Kustner" <ricardo＠rixhq.nu> -
bwarsaw＠beopen.com -
Gergely Madarasz -
Ricardo Kustner
-
Ricardo Kustner -
Robert Irie