[Mailman-Users] mailman installation gone wild
Eric Alan Solo
sambarino1337 at gmail.com
Wed Sep 15 16:49:42 CEST 2010
Ok, due to my lack of comprehension I'm going to just step through
this troubleshooting guide and let you know the results, hopefully you
will spot something that I am unable to see.
-------------------------
I'm going to assume Sendmail as the MTA (its still the most commonly
found - though postfix is gaining ground): Note however that the only
MTA specific items in this FAQ are item 3 about aliases which doesn't
apply to all MTA configurations; item 4 about smrsh which applies only
to sendmail, and item 11 about mm-handler which applies only to that
rarely used configuration.
1. Check_perms. In all cases you should start by checking the
permissions on the files that were setup:
~mailman/bin/check_perms
/* root at domain:/usr/lib/mailman/Mailman# check_perms
* /var/lib/mailman/bin bad group (has: root, expected list)
* /var/lib/mailman/scripts bad group (has: root, expected list)
* /var/lib/mailman/templates bad group (has: root, expected list)
* /var/lib/mailman/icons bad group (has: root, expected list)
* /var/lib/mailman/cgi-bin bad group (has: root, expected list)
* /var/lib/mailman/mail bad group (has: root, expected list)
* /var/lib/mailman/Mailman bad group (has: root, expected list)
* /var/lib/mailman/logs bad group (has: root, expected list)
* /var/lib/mailman/locks bad group (has: root, expected list)
* /var/lib/mailman/cron bad group (has: root, expected list)
* Problems found: 10
* Re-run as list (or root) with -f flag to fix
*
*/ > I tried running check_perms -f but it doesn't do anything, not
sure what the issue is here so I just moved on to look at other
things.
2. Cron/mailmanctl.
a. Mailman 2.0.x only - Make sure that the cron daemon is running
ps aux |grep cron |grep -v grep
/ * root 506 0.0 0.3 2380 808 ? Ss Sep03 0:00 cron
*/ > looks right to me
This will print out the process information about the cron daemon. If
it returns a blank line, then cron is NOT running. NOTE: Mailman
2.0.13 and lower does not run an independent daemon. The qrunner
process is run via cron.
b. Mailman 2.1.x - Later versions of Mailman, versions 2.1 and
above, need cron for certain support jobs, but not for normal mail
delivery. In Mailman 2.1.x there is an independent daemon called
mailmanctl. You need to make sure that the mailmanctl daemon is also
running
ps auxww| grep mailmanctl |grep -v grep
*/ list 29170 0.0 2.1 11296 5256 ? Ss Sep10 0:00
/usr/bin/python /usr/lib/mailman/bin/mailmanctl -s -q start
*/ > looks fine to me
If this returns a blank line then the Mailman daemon is not running! Also, do
ps auxww | egrep 'p[y]thon'
or
ps -fAww | egrep 'p[y]thon'
/* list 29170 0.0 2.1 11296 5256 ? Ss Sep10 0:00
/usr/bin/python /usr/lib/mailman/bin/mailmanctl -s -q start
* list 29171 0.0 2.8 10916 7012 ? S Sep10 0:46
/usr/bin/python /var/lib/mailman/bin/qrunner --runner=ArchRunner:0:1
-s
* list 29172 0.0 2.9 11292 7332 ? S Sep10 0:50
/usr/bin/python /var/lib/mailman/bin/qrunner --runner=BounceRunner:0:1
-s
* list 29173 0.0 2.8 10908 7004 ? S Sep10 0:46
/usr/bin/python /var/lib/mailman/bin/qrunner
--runner=CommandRunner:0:1 -s
* list 29174 0.0 2.8 10920 7032 ? S Sep10 0:47
/usr/bin/python /var/lib/mailman/bin/qrunner
--runner=IncomingRunner:0:1 -s
* list 29175 0.0 2.8 10896 7056 ? S Sep10 0:46
/usr/bin/python /var/lib/mailman/bin/qrunner --runner=NewsRunner:0:1
-s
* list 29176 0.0 3.0 11276 7488 ? S Sep10 0:48
/usr/bin/python /var/lib/mailman/bin/qrunner
--runner=OutgoingRunner:0:1 -s
* list 29178 0.0 2.8 10916 7232 ? S Sep10 0:45
/usr/bin/python /var/lib/mailman/bin/qrunner --runner=VirginRunner:0:1
-s
* list 29179 0.0 2.8 10908 7016 ? S Sep10 0:00
/usr/bin/python /var/lib/mailman/bin/qrunner --runner=RetryRunner:0:1
-s
*/ > looks fine to me
or however you might spell it on your system. This should show that
mailmanctl and eight qrunner processes are all running. See item 6.
below.
3. Aliases. To create a mailman list you ran "newlist" and it printed
out four (or ten) lines that you needed to copy to the /etc/aliases
file (or wherever your MTA goes to find its aliases). Check that the
aliases are in /etc/aliases:
grep wrapper /etc/aliases
Note for version 2.1: "wrapper" has been replaced with "mailman",
grep mailman /etc/aliases
Even if the aliases are there, you may still need to reset the aliases
hash table so that it includes this new alias information:
newaliases
Here is a typical alias listing for a group called "sys":
## Mailman verion 2.0.x system mailing list
sys: "|/home/mailman/mail/wrapper post sys"
sys-admin: "|/home/mailman/mail/wrapper mailowner sys"
sys-request: "|/home/mailman/mail/wrapper mailcmd sys"
sys-owner: sys-admin
And here's a typical list of aliases for the 'mailman' list in mailman 2.1.x.
## mailman mailing list
mailman: "|/usr/local/mailman/mail/mailman post mailman"
mailman-admin: "|/usr/local/mailman/mail/mailman admin mailman"
mailman-bounces: "|/usr/local/mailman/mail/mailman bounces mailman"
mailman-confirm: "|/usr/local/mailman/mail/mailman confirm mailman"
mailman-join: "|/usr/local/mailman/mail/mailman join mailman"
mailman-leave: "|/usr/local/mailman/mail/mailman leave mailman"
mailman-owner: "|/usr/local/mailman/mail/mailman owner mailman"
mailman-request: "|/usr/local/mailman/mail/mailman request mailman"
mailman-subscribe: "|/usr/local/mailman/mail/mailman subscribe mailman"
mailman-unsubscribe: "|/usr/local/mailman/mail/mailman unsubscribe mailman"
If you are using Sendmail with virtual domains, you will have to also
add entries into the into the 'virtusertable' to make the mapping for
the virtual domain to the local aliases previously setup, similiar to
the following:
## mailman virtual mappings
sys at virtdomain.com sys
sys-admin at virtdomain.com sys-admin
sys-request at virtdomain.com sys-request
sys-owner at virtdomain.com sys-admin
then run 'make' or 'makemap' to rebuild the virtusertable.db file and
restart sendmail. This solution is limited in that you can not have
multiple virtual domain with the same local address/list name. NOTE:
in mailman version 2.1 and above you may have a secondary aliases file
that is used specifically for Mailman and the lists that it creates:
~mailman/data/aliases
You will need to make sure that this alias file isrecognized by your
MTA (postfix, sendmail, etc), and that it is up-to-date with your
latest aliases. If you do not have integration turned on, or you do
not have this alias file, then all your aliases must go in the
standard /etc/aliases file as specified above.
/* I totally ignored aliases on setup etc because the installation
guide I was following said that I didn't need them, I "should" have
configured the MTA (exim4) to do */ that stuff according to that guide
4. Smrsh. Check to see if your MTA uses smrsh. Red Hat as well as a
few other distributions automatically setup Sendmail to use smrsh.
Smrsh stops Sendmail from running a script or other program that is
included in an alias. Mailman uses a program called "wrapper" to run
all of its aliases (see the alias examples above):
grep "smrsh" sendmail.cf
/* grep: sendmail.cf: No such file or directory
/* > makes no sense so I moved on
If this comes up blank then Sendmail does not use smrsh and the rest
of this section doesn't apply - skip to 5.; if not, then your server
is probably running smrsh and you need to make sure that smrsh is
setup to allow Mailman's wrapper program to run. Locate the smrsh
directory and do an ls -l of that directory. On Red Hat:
ls -l /etc/smrsh
and the output should be similar to:
wrapper -> /home/mailman/mail/wrapper
Note: some systems setup the smrsh directory in:
/usr/adm/sm.bin/
Note: to find the sm.bin directory try:
strings /usr/lib/smrsh | grep sm.bin
Note for version 2.1: the wrapper program is now simply called "mailman",
mailman -> /var/mailman/mail/mailman
5. Interface. Some distributions in a noble "attempt" to limit the
number of open relays on the internet, default Sendmail so that it
listens to a limited number of interfaces. The default interface that
Mailman list's use is "localhost" (127.0.0.1) - this is configurable
in Mailman's mm_cfg.py file. To check Sendmail's configuration file:
grep "Port" sendmail.cf
/* sendmail.cf: No such file or directory
*/ > makes no sense so I moved on
This will list out the DeamonPortOption and indicate the interfaces it
listens on (0.0.0.0 would mean all interfaces). You can also check out
which interfaces your MTA is listening on by using:
netstat -na |grep ":25 "
/* tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN
*/ > looks right to me
In a similar vein, some folks have reported that "localhost" is not
defined in their /etc/hosts file (it should be set to 127.0.0.1). Also
make sure /etc/hosts is world readable. Also see 4.73 How do I debug
smtp-failure problems - delivery to user-example.com failed with code
-1- and Low level smtp error-. The settings in
~mailman/Mailman/mm_cfg.py (or Defaults.py) that are used to set these
"Delivery Defaults":
DELIVERY_MODULE = 'SMTPDirect'
SMTPHOST = 'localhost'
SMTPPORT = 0 # default from smtplib
/* My settings do reflect those values
*/
6. qrunner.
Mailman 2.0.x only - If you are running Mailman 2.0.x then qrunner is
run every minute via a cron job (that is why cron must be running for
Mailman to work). Try running the program by hand. The exact syntax
can be found in Mailman's cron jobs:
su mailman
crontab -l
/* when i try to run crontab -l i get this:
* no crontab for root
*/ don't understand what I'm supposed to do
Here is an example of running qrunner by hand:
su mailman
/usr/bin/python -S /home/mailman/cron/qrunner
If this generates any errors then send those to the list for diagnosis
- or look at the last few lines of errors and search the list for key
words from the error messages.
Mailman 2.1.x - If you are running Mailman 2.1.x then the qrunners are
daemons that are started by $prefix/bin/mailmanctl, which itself may
be being run via a 'mailman' startup script. This is described in the
INSTALL document for the version of MM you are running. Note that
there are eight qrunners. These runners and their functions are:
ArchRunner # messages for the archiver
BounceRunner # for processing of bounces
CommandRunner # commands and confirmations from the outside world
IncomingRunner # posts from the outside world
NewsRunner # outgoing messages to the nntpd
OutgoingRunner # outgoing messages to the smtpd
VirginRunner # internally crafted (virgin birth) messages
RetryRunner # retry temporarily failed deliveries
If you aren't doing any gatwaying to usenet, you can do without
NewsRunner, and if you aren't archiving any lists, you can do without
ArchRunner, but the other six are required to be running for normal
Mailman operation. Also note that if any queues are 'sliced' there
will be more than one runner for that queue, and you need them all.
For example, if OutgoingRunner is set up for 4 slices, there will be
four copies of OutgoingRunner processing slices 0:4, 1:4, 2:4 and 3:4.
If any of these four is not running, its portion of the out queue will
not be processed.
7. Locks. A errant lock file can stop a list from processing as
Mailman waits for the lock to be removed. Since your list is not
sending, we shall assume that no lock files should be on the list and
that it is safe to delete any we find.
Note that we are talking here about locks with the list name as part
of the lock file name. The master-qrunner locks are normal and are not
the cause of non-delivery problems. On the contrary, if they
weren't there it would indicate that the qrunners weren't running.
ls -l ~mailman/locks
The output will be something like:
qrunner.lock.moya.trilug.org.22845
/* > I don't get that output, I get: "lrwxrwxrwx 1 root root 17
2010-09-10 05:45 locks -> /var/lock/mailman"
* > I know that's not really checking the locks but not sure what to do
* > I tried "ps aux | grep qrunner" and got
* root 14818 0.0 0.3 3332 824 pts/0 S+ 10:34 0:00 grep qrunner
*/ > along with the other 8 runners
This indicates that process # 22845 created the lock. To look at this
process and see what it is (if it still exists):
ps aux |grep 22845 |grep -v grep
8. Logs. If you don't have any of the common problems above, then you
should look for errors in your log files. First look for errors in
your MTA log files. On Red Hat that would be in /var/log/maillog. Look
in the log starting at the time you sent a test message. You should
see your initial message come in and be passed on to your Mailman
list, afterwards you may see warnings or errors caused by Mailman
trying to send out mail to the members of the list.
Next look in Mailman's logs. The files are in ~mailman/logs/ or
usually /var/log/mailman on RedHat.
There are several logs to look in for problems:
error
smtp-failure
smtp
vette
locks
post
qrunner
Note: if you look in the qrunner log you may see several warnings
about "Could not acquire qrunner lock", these are actually normal and
are NOT a problem, but other messages about qrunners terminating and
being restarted or not do indicate a problem.
Every line in the log files is dated so you should be able to isolate
the place in the log files to start looking, based on when your
problem started.
What do the logs and the times of the entries in your MTA show. Is it
passing the mail into the mailman alias properly? Check the time.
Now check the Mailman post log and when it shows the message accepted
for posting. The time should be very close to the MTA's time.
Now back to the MTA, does it show the message going out to the various
folks on the list?
/* There are no logs for any of the emails I try to send to the
mailman address, if I send a mail via the command line then there are
logs for it, also for the
*/ subscribed mail, both of those things do work though
9. Qfiles. You may have a malformed email (or one that is simply too
big) clogging up the flow of mail to your lists. Mail that is queued
up by Mailman is stored in the directory:
~mailman/qfiles
or in FHS compliant RedHat systems
/var/spool/mailman
/* All the qfiles directories are empty
*/
Move any files out of the directory and into a temporary directory,
then send a new test message to your list. If that works, then you can
move some of the old queued up files back and let those process. If it
stops working again then you have a bad message in that batch - delete
them or copy them to a different temporary directory.
Note that files accumulating in a queue directory can also mean that
its qrunner (or one of its slice qrunners) is not running. See 1b and
5b above
10. SMTPHOST. Mailman would accept messages but they wouldn't go
anywhere. logs/smtp would just show "All recipients refused: (61,
'Connection refused')". My mailserver is configured to listen only on
its external IP address, no localhost or anything like that. I had to
add to ~mailman/Mailman/mm_cfg.py:
SMTPHOST = '<ip of my mailserver>'
After that Mailman started working perfectly.
/* Seeing as there are no smtp logs I dont think there is a point to
changing it from my hostname to the ip
*/
11. Sendmail + mm-handler. If your mail is not getting to the mailing
list then try testing mm-handler independently of sendmail:
echo "From: jbloggs at hotmail.com
To: testlist at mailman.mydomain.com
Subject: Test
test mail body
" | /etc/mail/mm-handler mailman.mydomain.com \
-r jbloggs at hotmail.com testlist
To test with sendmail without your email client try:
echo "From: jbloggs at hotmail.com
To: testlist at mailman.mydomain.com
Subject: Test
test mail body
" | /usr/sbin/sendmail -fjbloggs at hotmail.com \
testlist at mailman.mydomain.com
Also try editing mm-handler and setting DEBUG=1 and rerun the sendmail
command above and see if you get a bounce.
/* I can send mail from command line
*/
12. Topics. If your list has topics defined, make sure users have
appropriate settings to receive the posts they want.
/* no topics
*/
13. Archives. If your list(s) have archives, do posts get archived? If
so, the problem is almost certainly in outgoing mail delivery. Focus
on OutgoingRunner, qfiles/out, the 'error', 'smtp' and 'smtp-failure'
logs and the logs of your MTA.
/* no archives, they're empty (and i'm going to turn them off anyway)
If none of the above steps helps, then try seeking out help on the
mailman-users at python.org mailing list. When submitting your problem to
the list please include the following information:
version of mailman you are running,
how it was installed (via rpm, apt-get, or source),
version of OS your server is running,
the MTA (sendmail, postfix, exim, qmail, etc) running on your server.
/* using...
* mailman 1:2.1.13-1
* exim4 4.71-3ubuntu1
* installed via apt-get
* on ubuntu 10.04 server
*/
-------------------------
Thanks for your time,
Eric
On Fri, Sep 10, 2010 at 4:59 PM, Eric Alan Solo <sambarino1337 at gmail.com> wrote:
> ok, thanks
>
> On Fri, Sep 10, 2010 at 4:54 PM, Mark Sapiro <mark at msapiro.net> wrote:
>> Eric Alan Solo wrote:
>>>
>>>Thanks for the response,
>>>I was chatting with some guys in the irc channel who helped me a bit,
>>>I'm now able to access the web interface.
>>>Also I was able to send a message from the console, so now I need to
>>>figure out why none of the mailman mails are being delivered.
>>
>>
>> See the FAQ at <http://wiki.list.org/x/A4E9>.
>>
>> --
>> Mark Sapiro <mark at msapiro.net> The highway is for gamblers,
>> San Francisco Bay Area, California better use your sense - B. Dylan
>>
>>
>
More information about the Mailman-Users
mailing list