No mail and no posts from mailman
![](https://secure.gravatar.com/avatar/63b58443729f0ae405ce86600caa888f.jpg?s=120&d=mm&r=g)
I am befuddled.
mailman-2.1.8-0.FC4.1 (from RPM) Fedora Core 4 (kept up to date with nightly yum) postfix-2.2.2-2 (from RPM)
This is an established list server that has had one functioning list (albeit very low volume, so I can't swear that it is still working).
I added a new list, put myself and one other person as the administrator, set it to send notifications of new subscribers, and subscribed both of us to the list.
Then I sent two test emails to the list, but they seem to have gone into a black hole. My workstation mail server sent them:
Feb 26 18:07:33 bobcat postfix/smtp[1119]: 5B3EF42C8: to=<foobarlist@lists.bobcatos.com>, relay=bubba.bobcatos.com[192.168.3.2], delay=0, status=sent (250 Ok: queued as AC98C2057) Feb 26 22:08:54 bobcat postfix/smtp[11974]: DFFA742C8: to=<foobarlist@lists.bobcatos.com>, relay=bubba.bobcatos.com[192.168.3.2], delay=1, status=sent (250 Ok: queued as 429CA2056)
My list server got it:
Feb 26 18:07:41 bubba postfix/local[17421]: AC98C2057: to=<foobarlist@lists.bobcatos.com>, relay=local, delay=0, status=sent (delivered to command: /usr/lib/mailman/mail/mailman post foobarlist) Feb 26 22:09:03 bubba postfix/local[20514]: 429CA2056: to=<foobarlist@lists.bobcatos.com>, relay=local, delay=1, status=sent (delivered to command: /usr/lib/mailman/mail/mailman post foobarlist)
But nothing came out. Nothing held for moderation. Nothing in the /var/log/mailman/* logs about them. Nothing in the archives. Following FAQ 3.14:
Did it.
# ps auxww| grep mailmanctl |grep -v grep mailman 7087 0.0 0.3 13048 1672 ? Ss 2006 0:00 /usr/bin/python /usr/lib/mailman/bin/mailmanctl -s -q start
ps auxww | egrep 'p[y]thon'
mailman 7087 0.0 0.3 13048 1672 ? Ss 2006 0:00 /usr/bin/python /usr/lib/mailman/bin/mailmanctl -s -q start mailman 7097 0.0 0.5 12912 2508 ? S 2006 0:00 /usr/bin/python /usr/lib/mailman/bin/qrunner --runner=RetryRunner:0:1 -s
- My /etc/mailman/aliases contains (among other things)
STANZA START: foobarlist
# CREATED: Sat Feb 24 18:33:52 2007 foobarlist: "|/usr/lib/mailman/mail/mailman post foobarlist" foobarlist-admin: "|/usr/lib/mailman/mail/mailman admin foobarlist" foobarlist-bounces: "|/usr/lib/mailman/mail/mailman bounces foobarlist" foobarlist-confirm: "|/usr/lib/mailman/mail/mailman confirm foobarlist" foobarlist-join: "|/usr/lib/mailman/mail/mailman join foobarlist" foobarlist-leave: "|/usr/lib/mailman/mail/mailman leave foobarlist" foobarlist-owner: "|/usr/lib/mailman/mail/mailman owner foobarlist" foobarlist-request: "|/usr/lib/mailman/mail/mailman request foobarlist" foobarlist-subscribe: "|/usr/lib/mailman/mail/mailman subscribe foobarlist" foobarlist-unsubscribe: "|/usr/lib/mailman/mail/mailman unsubscribe foobarlist" # STANZA END: foobarlist
And the aliases.db file was updated. But then we knew that from the maillog entries. Also, my postfix main.cf contains
alias_maps = hash:/etc/postfix/aliases, hash:/etc/mailman/aliases
But then we knew that from the maillog entries, too.
Smrsh (not applicable)
Interface: This is a full-bore company mail server and has serviced the other list just fine, not to mention Squirrelmail and several daemons and cron jobs that send mail.
qrunner: Mailman is started by /etc/rc.d/init.d/mailman, and
service mailman status
mailman (pid 7087) is running...
- Locks:
ls -l ~mailman/locks
ls: /usr/lib/mailman/locks: No such file or directory
- Logs: The only things in the logs are the subscriptions:
[root@bubba mailman]# cat qrunner Feb 25 04:08:42 2007 (7087) Master watcher caught SIGHUP. Re-opening log files. Feb 25 04:08:44 2007 (7097) RetryRunner qrunner caught SIGHUP. Reopening logs. [root@bubba mailman]# cat subscribe Feb 26 17:42:35 2007 (10359) foobarlist: new bob@bobcatos.com, admin mass sub Feb 26 17:42:35 2007 (10359) foobarlist: new otherperson@domain.com, admin mass sub
The only thing in error is the result of running mailmanctl with no arguments. /var/log/mailman/smtp is zero-length.
- Qfiles: # ls -l ~mailman/qfiles ls: /usr/lib/mailman/qfiles: No such file or directory
locate qfiles
/usr/lib/mailman/bin/show_qfiles
Okay, with this and (6), I'm wondering if some directories are missing. But if so, why is (or was) the other list functioning, and why is there nothing in the logs about it?
Also, the server has been up for 216 days, and the other list was created since the last boot, so there's been no system crash to take something out.
SMTPHOST: /var/log/mailman/smtp shows no signs of distress, in fact, it is zero-length (and owned by mailman).
Sendmail + mm-handler (not applicable)
For FAQ 1.7:
a) N/A since this is v2.1.8.
b, c, and d) Aliases are ok by inspection and log entries, above.
e) qrunner is running.
f) No messages for moderation.
g) /etc/mailman/mm_cfg.py contains
DEFAULT_URL_HOST = "www.bobcatos.com" DEFAULT_EMAIL_HOST = "lists.bobcatos.com" add_virtualhost(DEFAULT_URL_HOST, DEFAULT_EMAIL_HOST)
What clues am I missing?
Cheers,
Bob McClure, Jr. Bobcat Open Systems, Inc. bob@bobcatos.com http://www.bobcatos.com "But what about you?" Jesus asked. "Who do you say I am?" Peter answered, "You are the Christ." Mark 8:29 (NIV)
![](https://secure.gravatar.com/avatar/746f7519ba02fb0d815e59f305c53fa2.jpg?s=120&d=mm&r=g)
Bob McClure Jr wrote:
Seven of eight qrunner processes are missing. Please reread FAQ 3.14, sec 1, and let us know how to emphasize that all eight qrunners should be running.
I think in FC4 you'll find them in /var/locks/mailman.
Your logs rotate. (The default for Fedora is weekly for 4 generations I think.) Check the old qrunner.[1234] and error.[1234] logs to see if there is info there as to why the qrunners died.
Meanwhile, manually do 'bin/mailmanctl stop' and 'bin/mailmanctl start'. Don't do just a restart.
I think they're in /var/spool/mailman, and you'll find all your messages in the 'in' queue and the 'virgin' queue and they will be sent when Mailman's qrunners are running again.
They're not missing. You just aren't looking in the right places. And the log entries have rotated to older logs or oblivion.
What clues am I missing?
See above.
-- Mark Sapiro <msapiro@value.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
![](https://secure.gravatar.com/avatar/63b58443729f0ae405ce86600caa888f.jpg?s=120&d=mm&r=g)
On Wed, Feb 28, 2007 at 07:32:49AM -0800, Mark Sapiro wrote:
I wondered about that, but when I ran "mailmanctl status", it didn't report anything amiss, so I didn't know what to think. Now I know that there are eight of those suckers to account for.
/var/lock/mailman, actually. Thanks for the clue.
There are no clues in there, so they must have died over a month ago. Do I need to put in a cron-driven monitor to check up on the qrunners or is there a more sophisticated way to do that?
Meanwhile, manually do 'bin/mailmanctl stop' and 'bin/mailmanctl start'. Don't do just a restart.
Excellent! It's up and has flushed all the messages it had queued. Thank you, sir.
Ah, another great clue. Never thought of looking there, though it's perfectly logical.
Yep.
What clues am I missing?
See above.
Excellent! Thank you again.
Cheers,
Bob McClure, Jr. Bobcat Open Systems, Inc. bob@bobcatos.com http://www.bobcatos.com Jesus looked at them and said, "With man this is impossible, but with God all things are possible." Matthew 19:26 (NIV)
![](https://secure.gravatar.com/avatar/746f7519ba02fb0d815e59f305c53fa2.jpg?s=120&d=mm&r=g)
Bob McClure Jr wrote:
The RedHat implementation of 'mailmanctl status' (see <http://sourceforge.net/tracker/index.php?func=detail&aid=1208685&group_id=103&atid=300103>) is intended to provide a way to check, but it only checks the master mailmanctl process. If one or more runners has died in a way that it won't be restarted, or has reached the restart limit, 'mailmanctl status' can look OK when things really aren't.
Looking for all the qrunners periodically with a cron is good. Something else which is good is Brad's daily status report script <http://sourceforge.net/tracker/index.php?func=detail&aid=1123383&group_id=103&atid=300103>. This runs daily at midnight via cron and checks some directories and looks for various things in logs and mails a report. It requires a small modification which is attached or it will miss the initial portion of the day that logs rotate, but it is quite good.
The patch should only be applied if logs are rotated as it assumes the existance of a '.1' log without checking.
-- Mark Sapiro <msapiro@value.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
![](https://secure.gravatar.com/avatar/746f7519ba02fb0d815e59f305c53fa2.jpg?s=120&d=mm&r=g)
Bob McClure Jr wrote:
Seven of eight qrunner processes are missing. Please reread FAQ 3.14, sec 1, and let us know how to emphasize that all eight qrunners should be running.
I think in FC4 you'll find them in /var/locks/mailman.
Your logs rotate. (The default for Fedora is weekly for 4 generations I think.) Check the old qrunner.[1234] and error.[1234] logs to see if there is info there as to why the qrunners died.
Meanwhile, manually do 'bin/mailmanctl stop' and 'bin/mailmanctl start'. Don't do just a restart.
I think they're in /var/spool/mailman, and you'll find all your messages in the 'in' queue and the 'virgin' queue and they will be sent when Mailman's qrunners are running again.
They're not missing. You just aren't looking in the right places. And the log entries have rotated to older logs or oblivion.
What clues am I missing?
See above.
-- Mark Sapiro <msapiro@value.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
![](https://secure.gravatar.com/avatar/63b58443729f0ae405ce86600caa888f.jpg?s=120&d=mm&r=g)
On Wed, Feb 28, 2007 at 07:32:49AM -0800, Mark Sapiro wrote:
I wondered about that, but when I ran "mailmanctl status", it didn't report anything amiss, so I didn't know what to think. Now I know that there are eight of those suckers to account for.
/var/lock/mailman, actually. Thanks for the clue.
There are no clues in there, so they must have died over a month ago. Do I need to put in a cron-driven monitor to check up on the qrunners or is there a more sophisticated way to do that?
Meanwhile, manually do 'bin/mailmanctl stop' and 'bin/mailmanctl start'. Don't do just a restart.
Excellent! It's up and has flushed all the messages it had queued. Thank you, sir.
Ah, another great clue. Never thought of looking there, though it's perfectly logical.
Yep.
What clues am I missing?
See above.
Excellent! Thank you again.
Cheers,
Bob McClure, Jr. Bobcat Open Systems, Inc. bob@bobcatos.com http://www.bobcatos.com Jesus looked at them and said, "With man this is impossible, but with God all things are possible." Matthew 19:26 (NIV)
![](https://secure.gravatar.com/avatar/746f7519ba02fb0d815e59f305c53fa2.jpg?s=120&d=mm&r=g)
Bob McClure Jr wrote:
The RedHat implementation of 'mailmanctl status' (see <http://sourceforge.net/tracker/index.php?func=detail&aid=1208685&group_id=103&atid=300103>) is intended to provide a way to check, but it only checks the master mailmanctl process. If one or more runners has died in a way that it won't be restarted, or has reached the restart limit, 'mailmanctl status' can look OK when things really aren't.
Looking for all the qrunners periodically with a cron is good. Something else which is good is Brad's daily status report script <http://sourceforge.net/tracker/index.php?func=detail&aid=1123383&group_id=103&atid=300103>. This runs daily at midnight via cron and checks some directories and looks for various things in logs and mails a report. It requires a small modification which is attached or it will miss the initial portion of the day that logs rotate, but it is quite good.
The patch should only be applied if logs are rotated as it assumes the existance of a '.1' log without checking.
-- Mark Sapiro <msapiro@value.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
participants (2)
-
Bob McClure Jr
-
Mark Sapiro