All of our mailman logs are in /var/mailman/logs, and that's my only indication of the problems I attached initially..
However.. I did find something of interest. It seems that the major backlog of messages I had were about 80-100 bogus messages. What I mean, is that they were all dated about 3-5 months old. I removed them completely (they kept appearing in the "out" directory, then they would get moved to the "shunt" directory, then back again depending upon restarts).
Additionally, I set up Nagios to monitor the number of items in the "out" directory just to see if anything gest hung.. things look good so far..
-Rich
Did you look for errors in /var/log/maillog?
Which SMTP method are you using in mailman? Direct?
What is your MTA? Is it local?
Did you look for errors in /var/log/messages?
I assume you looked at all the log files in /var/log/mailman, including the errors log, other than what you saw in the smtp log did you see anything else?
Do you have disk space left?
On Fri, 2004-10-22 at 12:09, Rich West wrote:
I migrated our main server from Fedora Core 1 (running our own built version of mailman 2.1.5) to another server running a fresh install of Fedora Core 2 (running our own built version of mailman 2.1.5) about two weeks ago.
Since that time, we have had continual problems with our mailman installation.
Our installation is pretty vanilla, and it handles about 30+ lists with some lists having low membership and others having hundreds of addresses.
Anyhow, on the FC1 machine, everything ran fine since we rolled that in to production back in January of this year, and previously, under RedHat 9, things ran seamlessly as well.
Since we have upgraded to Fedora Core 2, we're getting some odd problems that are just frustrating the living daylights out of me.
The problem shows itself when we get a report of no activity on any of the lists. Quick investigation shows that /var/mailman/qfiles/out is full of pending messages. Unsure as to why they are pending, we quickly restart the mailman daemon. Unfortunately, two of the processes don't die ("mailmanctl -s start" and "OutgoingRunner"), so they have to be killed manually. Bringing mailman back on-line begins the processing again, but I am not certain that it is even processing correctly.
On our test list, it does seem to send to *some* of the test users, but not all.
The smtp-error log periodically shows a gazillion "Low level SMTP error: (111, 'Connection refused')" messages followed by a gazillion "Low level smtp error: please run connect()first" and finally a gazillion "delivery to <emailaddress> failed with code -1: please run connect() first"
I've gone through and insured that my mm_cfg.py contained all of the right information, and I have even gone through the effort to compile it up (not sure if this is even necessary, but I am running out of ideas) via : python -c "import compileall; compileall.compile_dir('/var/mailman/Mailman', ddir='/var/mailman/Mailman')"
The mail server is working fine for all other types of delivery (confirmed easily). I'm at a complete loss at this point.. Is there any way to turn up the debugging information to see what host it is getting the "Connection refused" message from?
Also, I'm monitoring the qfiles/out directory.. I've been watching it for about a half hour and have watched the directory's contents continually grow after a fresh restart of mailman. It just doesn't seem to send. :(
Argh! Totally frustrating as we never had any problems with mailman before.. Any help, ideas, comments, etc, would be wonderful!!
-Rich
------------------------------------------------------ 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/
