FAQ
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.

--

Search Discussions

  • Barry A. Warsaw at Jun 29, 2000 at 6:45 am
    "RK" == Ricardo Kustner <ricardo at 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
  • Gergely Madarasz at Jun 29, 2000 at 12:22 pm
    On Thu, 29 Jun 2000, Barry A. Warsaw wrote:
    "RK" == Ricardo Kustner <ricardo at 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 at caesar.elte.hu gorgo at 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/
  • Barry A. Warsaw at Jul 10, 2000 at 6:12 pm
    "GM" == Gergely Madarasz <gorgo at 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
  • Robert Irie at Jul 10, 2000 at 9:04 pm

    -----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

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupmailman-users @
categoriespython
postedJun 29, '00 at 6:22a
activeJul 10, '00 at 9:04p
posts5
users4
websitelist.org

People

Translate

site design / logo © 2022 Grokbase