Hi all--
I've got a tricky problem on my mailman server. Right now, I have admin_immed_notify set to yes, but I'm not getting notifications when there are emails to approve. I'm also not getting the once-a-day "# list moderator request(s) waiting" either. "Forward messages (individually) to:" doesn't work. They all mysteriously stopped last Friday.
I'm running Exim version 4.50 #1, Mailman 2.1.5, Python 2.3.5, and Linux version 2.6.16.13-xenU (Red Hat 4.0.2-8 running on Xen).
I rebooted the server ("have you tried turning it off and turning it on again?") and the restarted the exim daemon and ran check_perms, to no avail.
I can email listname-owner (and it goes through), I can send email from the server, and list emails go out to the lists just fine. It only appears to be the administrator notifications and the forward messages individually to that are affected.
I looked at FAQ 4.73:
http://wiki.list.org/display/DOC/4.73+How+do+I+debug+smtp-failure+problems+-...
I can telnet into my SMTP port and send mail. I looked at the MTA logs and they seem fine. (They're below.) I'm not running Python 2.4, so I can't do the error log trick
I looked at FAQ 6.14:
http://wiki.list.org/pages/viewpage.action?pageId=4030722
I don't get any errors when I run the two python scripts interactively as the mailman user.
Here's what I'm getting in /var/lib/mailman/logs/smtp-failure:
Feb 25 13:54:52 2009 (1052) delivery to administrator@example.com failed with code -1: Connection unexpectedly closed Feb 25 14:32:49 2009 (1052) Low level smtp error: (111, 'Connection refused'), msgid: <msgid@list.example.com> Feb 25 14:32:49 2009 (1052) delivery to administrator@example.com failed with code -1: (111, 'Connection refused') Feb 25 14:34:02 2009 (1052) Low level smtp error: (111, 'Connection refused'), msgid: <msgid@www.example.org> Feb 25 14:34:02 2009 (1052) Low level smtp error: please run connect() first, msgid: <msgid@www.example.org>
Feb 25 14:35:55 2009 (1052) Low level smtp error: (111, 'Connection refused'), msgid: <msgid@list.example.com> Feb 25 14:35:55 2009 (1052) delivery to administrator@example.com failed with code -1: (111, 'Connection refused')
Here's what's in /var/log/exim4/mainlog:
2009-02-25 17:17:10 1LcS3p-0003iA-Ek => administrator@example.comR=dnslookup T=remote_smtp H= ASPMX.L.GOOGLE.com [209.85.217.8] 2009-02-25 17:17:10 1LcS3p-0003iA-Ek Completed 2009-02-25 17:17:24 1LcS46-0003iH-Cj => administrator@example.comR=dnslookup T=remote_smtp H= ASPMX.L.GOOGLE.com [209.85.217.8] 2009-02-25 17:17:24 1LcS46-0003iH-Cj Completed
(These are for a different message, but are representative.)
There doesn't seem to be anything in rejectlog.
I've tried changing the list administrator to a different email address by a different provider, but that doesn't seem to change anything.
Help?
Best,
george
Hi all--
Ummm... strangely, this appears to be working again. Not sure why, but I'm happy!
george
On Wed, Feb 25, 2009 at 5:29 PM, george bannerman <georgebannerman@gmail.com
wrote:
Hi all--
I've got a tricky problem on my mailman server. Right now, I have admin_immed_notify set to yes, but I'm not getting notifications when there are emails to approve. I'm also not getting the once-a-day "# list moderator request(s) waiting" either. "Forward messages (individually) to:" doesn't work. They all mysteriously stopped last Friday.
I'm running Exim version 4.50 #1, Mailman 2.1.5, Python 2.3.5, and Linux version 2.6.16.13-xenU (Red Hat 4.0.2-8 running on Xen).
I rebooted the server ("have you tried turning it off and turning it on again?") and the restarted the exim daemon and ran check_perms, to no avail.
I can email listname-owner (and it goes through), I can send email from the server, and list emails go out to the lists just fine. It only appears to be the administrator notifications and the forward messages individually to that are affected.
I looked at FAQ 4.73:
http://wiki.list.org/display/DOC/4.73+How+do+I+debug+smtp-failure+problems+-...
I can telnet into my SMTP port and send mail. I looked at the MTA logs and they seem fine. (They're below.) I'm not running Python 2.4, so I can't do the error log trick
I looked at FAQ 6.14:
http://wiki.list.org/pages/viewpage.action?pageId=4030722
I don't get any errors when I run the two python scripts interactively as the mailman user.
Here's what I'm getting in /var/lib/mailman/logs/smtp-failure:
Feb 25 13:54:52 2009 (1052) delivery to administrator@example.com failed with code -1: Connection unexpectedly closed Feb 25 14:32:49 2009 (1052) Low level smtp error: (111, 'Connection refused'), msgid: <msgid@list.example.com> Feb 25 14:32:49 2009 (1052) delivery to administrator@example.com failed with code -1: (111, 'Connection refused') Feb 25 14:34:02 2009 (1052) Low level smtp error: (111, 'Connection refused'), msgid: <msgid@www.example.org> Feb 25 14:34:02 2009 (1052) Low level smtp error: please run connect() first, msgid: <msgid@www.example.org>
Feb 25 14:35:55 2009 (1052) Low level smtp error: (111, 'Connection refused'), msgid: <msgid@list.example.com> Feb 25 14:35:55 2009 (1052) delivery to administrator@example.com failed with code -1: (111, 'Connection refused')
Here's what's in /var/log/exim4/mainlog:
2009-02-25 17:17:10 1LcS3p-0003iA-Ek => administrator@example.comR=dnslookup T=remote_smtp H= ASPMX.L.GOOGLE.com [209.85.217.8] 2009-02-25 17:17:10 1LcS3p-0003iA-Ek Completed 2009-02-25 17:17:24 1LcS46-0003iH-Cj => administrator@example.comR=dnslookup T=remote_smtp H= ASPMX.L.GOOGLE.com [209.85.217.8] 2009-02-25 17:17:24 1LcS46-0003iH-Cj Completed
(These are for a different message, but are representative.)
There doesn't seem to be anything in rejectlog.
I've tried changing the list administrator to a different email address by a different provider, but that doesn't seem to change anything.
Help?
Best,
george
George Bannerman wrote:
I've got a tricky problem on my mailman server. Right now, I have admin_immed_notify set to yes, but I'm not getting notifications when there are emails to approve. I'm also not getting the once-a-day "# list moderator request(s) waiting" either. "Forward messages (individually) to:" doesn't work. They all mysteriously stopped last Friday.
I'm running Exim version 4.50 #1, Mailman 2.1.5, Python 2.3.5, and Linux version 2.6.16.13-xenU (Red Hat 4.0.2-8 running on Xen).
Reading this reminded me that I have a similar problem. All of our lists are set by default to be admin_immed_notify=yes, but the list owners only get a message when something new arrives (that is put on hold). They never get a daily reminder about the queued-up stuff. Is this a known problem for v2.1.5 (we will be upgrading to v2.1.12 this summer). I have no idea how long this has been going on, and only remembered it because I own one of the lists and realized that I only get the one warning.
Thanks!
PS Our set-up:
RedHat Enterprise Linux AS release 4 (Nahant Update 6) Python 2.3 Exim 4.69 Mailman v2.1.5
Savoy, Jim wrote:
Reading this reminded me that I have a similar problem. All of our lists are set by default to be admin_immed_notify=yes, but the list owners only get a message when something new arrives (that is put on hold). They never get a daily reminder about the queued-up stuff. Is this a known problem for v2.1.5 (we will be upgrading to v2.1.12 this summer). I have no idea how long this has been going on, and only remembered it because I own one of the lists and realized that I only get the one warning.
The daily summary is sent by cron/checkdbs.
Does mailman have a crontab? Does it have an entry to run cron/checkdbs daily? Is crond running?
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Jim Savoy wrote:
Reading this reminded me that I have a similar problem. All of our lists are set by default to be admin_immed_notify=yes, but the list owners only get a message when something new arrives (that is put on hold). They never get a daily reminder about the queued-up stuff. Is this a known problem for v2.1.5 (we will be upgrading to v2.1.12 this summer). I have no idea how long this has been going on, and only remembered it because I own one of the lists and realized that I only get the one warning.
Mark Shapiro wrote:
The daily summary is sent by cron/checkdbs.
Does mailman have a crontab? Does it have an entry to run cron/checkdbs daily? Is crond running?
Hi Mark,
The answers to your questions are: yes, yes & yes. But I don't think the person who installed Mailman many years ago ever did the "crontab -u mailman crontab.in" bit, so I just did it now. First I commented out everything in that crontab.in file except the checkdbs line, and set that to run immediately. It worked like a charm and sent out hundreds of reminders to all list owners.
I am not all that familiar with cron. Is that "crontab -u mailman crontab.in" something you need to run every time you reboot the system? Or does it add something to /etc/cron.d or /etc/cron.daily or /etc/crontab? (I don't see anything new in those).
But I noticed that many of the reminders it sent out, pointing people to the admindb page were blank (ie there is nothing pending). So I'm not sure what that means. There aren't that many .pck files in /mailman/data and I am not sure where else it is pulling that false information from. The next run is set for 8:00 am tomorrow, but I might have to put it on hold until I find out why there are so many bogus warnings going out. If someone was to clear out a bunch of pending requests from the mailman/data directory just by deleting them, instead of doing it properly with the admindb web interface, would that cause this problem? If so, can I remedy this somehow? Any pointers would be helpful. I don't fully understand all of the workings of Mailman (like many of the others on this list - I just sort of babysit it and we've never had too many problems). Thanks!
Jim Savoy wrote:
I am not all that familiar with cron. Is that "crontab -u mailman crontab.in" something you need to run every time you reboot the system? Or does it add something to /etc/cron.d or /etc/cron.daily or /etc/crontab? (I don't see anything new in those).
Jim Savoy answers himself:
Before I get blasted with RTFMs, I did just read the manpage for crontab, and it says that each user may maintain their own separate crontabs, so I have now deduced that the command I ran activated that. I am still not sure if I am supposed to run that every time we reboot or if it's permanent (and if I change crontab.in (to comment out tomorrow's 8:00 am run, for instance) do I have to execute that command again?). Thanks.
I think I have my phantom requests (eg the "-1 request(s) pending") question answered. Googling it I see that Mark provided a fix, but also said that by going to that admin page once should clear it. That may save me from manually having to fix hundreds of lists.
Savoy, Jim wrote:
The answers to your questions are: yes, yes & yes. But I don't think the person who installed Mailman many years ago ever did the "crontab -u mailman crontab.in" bit, so I just did it now. First I commented out everything in that crontab.in file except the checkdbs line, and set that to run immediately. It worked like a charm and sent out hundreds of reminders to all list owners.
I am not all that familiar with cron. Is that "crontab -u mailman crontab.in" something you need to run every time you reboot the system? Or does it add something to /etc/cron.d or /etc/cron.daily or /etc/crontab? (I don't see anything new in those).
As you discovered it puts the commands from crontab.in into the mailman user's crontab which is likely /var/spool/cron/mailman. It stays there across boots.
This is the correct place for the mailman crontab. The ones in cron.d are a slightly different format.
But note, that almost all the jobs in crontab.in should be run. They all have a function and the only one you can safely ignore is gate_news if you aren't running any lists with a news->mail gateway.
For the others, you need to at least read the comments in crontab.in and understand what the job does before deciding not to run it.
But I noticed that many of the reminders it sent out, pointing people to the admindb page were blank (ie there is nothing pending).
Presumably these are the "-1 requests" ones you refer to later.
This issue only existed with lists that were migrated from pre 2.1.5 to 2.1.5 and only exists in 2.1.5.
Yes, visiting the list's admindb page should fix it, but that needs to be done for each list with the problem.
I have just created a withlist script you can run to fix all the problem lists. See <http://www.msapiro.net/scripts/fix_minus_one.py>.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Jim Savoy wrote:
I am not all that familiar with cron. Is that "crontab -u mailman crontab.in" something you need to run every time you reboot the system? Or does it add something to /etc/cron.d or /etc/cron.daily or /etc/crontab? (I don't see anything new in those).
Mark Sapiro wrote:
As you discovered it puts the commands from crontab.in into the mailman user's crontab which is likely /var/spool/cron/mailman. It stays there across boots.
This is the correct place for the mailman crontab. The ones in cron.d are a slightly different format.
Got it. And yes, there is an entry now in /var/spool/cron for mailman.
But note, that almost all the jobs in crontab.in should be run. They all have a function and the only one you can safely ignore is gate_news if you aren't running any lists with a news->mail gateway.
I will run more of them eventually. Since we hadn't run any of these in years (ever, in fact) I thought it might be a bad idea to "release the hounds" all at once. The madness that took place with the "-1 pending requests" confirmed that. By the way - thanks for your excellent script. Saved me and the owners the hassle of fixing the minus-one problem (243 lists were in that state and they are all fixed now!).
For the others, you need to at least read the comments in crontab.in and understand what the job does before deciding not to run it.
I will probably leave the gateway news stuff out forever. And also the password reminder thing, as we don't want to bombard our students with more info (most of our 900+ lists are NOT opt-in, and most are read-only, and we rotate thousands of different users through these lists each semester, without their knowledge). I probably won't run the "disabled users" reminder either, for the same reason as above.
So that just leaves two more things to run via cron: digests and archive gzipping. I will run the digests thing next and if that goes smoothly, unleash the archive gzipping.
This issue only existed with lists that were migrated from pre 2.1.5 to 2.1.5 and only exists in 2.1.5.
Precisely our situation. Thanks.
- jim -
Savoy, Jim wrote:
Mark Sapiro wrote:
For the others, you need to at least read the comments in crontab.in and understand what the job does before deciding not to run it.
I will probably leave the gateway news stuff out forever. And also the password reminder thing, as we don't want to bombard our students with more info (most of our 900+ lists are NOT opt-in, and most are read-only, and we rotate thousands of different users through these lists each semester, without their knowledge).
Fair enough, although the sending of reminders is a list option. You can set
DEFAULT_SEND_REMINDERS = No
in mm_cfg.py and see the FAQ at <http://wiki.list.org/x/MIBp> for the easy way to set send_reminders to No for existing lists, and then you could set send_reminders to Yes for those few lists where it might be useful.
I probably won't run the "disabled users" reminder either, for the same reason as above.
This has a side effect which may not be important in your environment. If bounce processing is enabled for a list and bounce_you_are_disabled_warnings is set > 0, when a user's bounce score reaches the threshold, the users delivery is disabled by bounce and the first notice is sent. From there the entire process of sending subsequent notices and removing bouncing members from the list is don by cron/disabled, so if you have bounce processing is enabled for a list and bounce_you_are_disabled_warnings is set > 0 and you don't run cron/disabled, the members who have been disabled by bounce will never be removed.
So that just leaves two more things to run via cron: digests and archive gzipping. I will run the digests thing next and if that goes smoothly, unleash the archive gzipping.
Actually, gzipping of the archive is the one I don't run. It doesn't save any space because the monthly .txt files are still kept as well as the .txt.gz files, but the .txt.gz file will be served in preference to the .txt file if it exists, even if it is up to a day old.
The only thing you save is maybe some bandwidth in serving the file, but the web server may be gunzipping the file and serving the plain text anyway, so maybe you save nothing.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Jim Savoy wrote:
I will probably leave the gateway news stuff out forever. And also the password reminder thing, as we don't want to bombard our students with more info...
Mark Sapiro wrote:
Fair enough, although the sending of reminders is a list option. You can set
DEFAULT_SEND_REMINDERS = No
Yep - that is the default we have set for all lists, so passwords have to be found by the user themselves (through the links in their email) or by sending me mail.
So I guess the downside to not running that cron job is that if an owner changed that setting, nothing would happen as far as a monthly reminder goes.
I probably won't run the "disabled users" reminder either, for the same reason as above.
This has a side effect which may not be important in your environment. If bounce processing is enabled for a list and bounce_you_are_disabled_warnings is set > 0, when a user's bounce score reaches the threshold, the users delivery is disabled by bounce and the first notice is sent. From there the entire process of sending subsequent notices and removing bouncing members from the list is don by cron/disabled, so if you have bounce processing is enabled for a list and bounce_you_are_disabled_warnings is set > 0 and you don't run cron/disabled, the members who have been disabled by bounce will never be removed.
I see. OK I will add this one in a bit later on to clean up some of these lists. Some of our more ancient lists that are not updated by cron (and have most likely been abandoned) have nothing but bad addresses subscribed to them. Now I know why!
So that just leaves two more things to run via cron: digests and archive gzipping. I will run the digests thing next and if that goes smoothly, unleash the archive gzipping.
Actually, gzipping of the archive is the one I don't run.
I won't either then (!). I was only considering running that to save space anyway, but I can probably free up lots of archive space by deleting some abandoned lists.
Thanks Mark.
- jim -
participants (3)
-
george bannerman -
Mark Sapiro -
Savoy, Jim