b3 not working anymore?
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, 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...
"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
-----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 (4)
-
bwarsaw＠beopen.com -
Gergely Madarasz -
Ricardo Kustner -
Robert Irie