At 19:56 25/03/2003, ghhalley wrote:
Thanks for the help,
OK mailmanctl was not running. I started it up and got a confirmation
message.
It should have been running, as the the Mailman init.d files are already
set to run.
Is mailmanctl daemon always on? Should I see it with ps -e at all
times?
With MM 2.1.1 yes and yes. Running ps -e should also show a number of
python processes; these are the qrunner subprocesses spawned by mailmanctl
and described briefly below.
With the earlier 2.0.x version the functions performed by mailmancntl were
performed by the qrunner cron script.
What is its purpose? I thought the Mailman wrapper was the major
program -- is this just a traffic manager and logger? or does it do
greater functions?
What follows is just my take on how MM 2.1.1 operates but I am open to
correction ...
When the MTA delivers incoming mail to Mailman it is injected (typically)
with minimal processing, into the incoming message queue by the script
executed by the $exec-prefix/mail/mailman wrapper. The situation is a
actually a bit more complicated because the script run depends on which
list related mail alias the message is addressed to, but you get the picture.
Doing minimal processing at incoming message delivery time avoids potential
problems with mail delivery to MM being timed out by the delivering MTA. It
means that incoming mail is less likely to be baulked out of delivery to MM
during periods of high system load.
The subsequent processing of messages is done using a pipeline of
activities defined in $prefix/Mailman/Defaults.py (actually there can be
different pipelines used dpending on what type of incoming message is being
handled).
In passing through the pipeline, messages may be removed from one queue and
injected into another for further processing.
mailmancntl spawns a series of subprocesses. Iteratively, each subprocess
takes a message from a particular queue, processes it and, if necessary,
injects it into the next queue. These subprocesses are what move the
messages down the pipeline of actions until they passed to the outgoing MTA
for delivery to subscribers.
The bulk of Mailman's work is done by the subprocesses supervised by
mailmanctl.
George
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
ghhalley wrote:
Upgraded my RH 8 to Python 2.2.2 and Mailman 2.1.1
[...]
Currently, I am receiving no email from Mailman.
Emails going into Mailman are received. After my initial tests and 3 days
of debugging, the Sendmail logs seemed normal and all of the QFiles had a
backlog. So I thought, maybe a qfile was jamming the system. I moved the
qfile files to temporarily directory. Then tried subscribing through the
user website and my virgin qfile has 10 files in it (nothing in the other
qfiles). I have not received any type of confirmation email and am not
listed on the admin subscription page.
Any ideas what is preventing the completion of Mailman?
Is mailmanctl running? This is different than the way the qrunners worked
in 2.0.x, where they ran from a cron job. They now are run via the
mailmanctl daemon.
Could it be a security or interface problem with Sendmail?
I don't think so, usually if that's the case you see smrsh errors.
Could it be a problem with the Mailman database or within the program?
I guess that's possible. If mailmanctl is indeed started, look for clues
in the mailman logs directory.
- --
Todd OpenPGP - KeyID: 0xD654075A | URL: www.pobox.com/~tmz/pgp
--
Mailman-Users mailing list
[EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
This message was sent to: [EMAIL PROTECTED]
Unsubscribe or change your options at
http://mail.python.org/mailman/options/mailman-users/archive%40jab.org
