mail not going out; no logs
Hi
I had a successful mailman installation running on one server. Due to some HW issues on that server that we have not been able to address, the mailman installation was moved to a different, similar server. The qrunners all run, and the cgi stuff works for UI of the lists, but no messages are sent out. The MTA is exim.
When a mail comes in for a list, exim successfully delivers the mail to mailman. The message DOES appear in qfiles/in for a second or two before mailman grabs it. It then next shows up in data/heldmsg-LISTNAME-nnn.pck and is not sent out. This happens regardless of "emergency moderation" being sent, and if you go to the admin UI for the list, there are NO pending moderation requests showing.
logs/ shows nothing except when the qrunners start and stop (successfully).
I have exhausted my knowledge on debugging this and would appreciate some help in figuring out what is going on. (I did upgrade mailman to see if that helped but the problem remains, so no permissions got fixed that way)
check_perms only flags a few cgi related things which need to be different due to group of the web server and the way suexec works. (no g+s, different group name, non writable by group directory)
check_db flags nothing
bin/dumpdb lists/LISTNAME/request.pck [----- start pickle file -----] <----- start object 1 -----> {'version': (0, 1)} [----- end pickle file -----]
Thanks Chad
chad+mailman@shire.net wrote:
I had a successful mailman installation running on one server. Due to some HW issues on that server that we have not been able to address, the mailman installation was moved to a different, similar server. The qrunners all run, and the cgi stuff works for UI of the lists, but no messages are sent out. The MTA is exim.
When a mail comes in for a list, exim successfully delivers the mail to mailman. The message DOES appear in qfiles/in for a second or two before mailman grabs it. It then next shows up in data/heldmsg-LISTNAME-nnn.pck and is not sent out. This happens regardless of "emergency moderation" being sent, and if you go to the admin UI for the list, there are NO pending moderation requests showing.
The message is being held for some reason. Mailman's vette log will tell you why, and it should appear on the list's admindb interface.
logs/ shows nothing except when the qrunners start and stop (successfully).
If you don't see anything in Mailman's vette log, there is either a permissions issue in writing the logs or you are not looking at the correct logs.
If you don't see the held message in the admindb interface, the web server is pointing at the wrong Mailman installation.
check_db is a very minimal test. It only checks that config.pck* can be successfully unpickled.
Are you certain you are looking at the correct Mailman installation?
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Turns out this is an embarrassing case of user being an idiot. I was looking in the wrong list admin UI. There are two lists with similar names and for some reason I was logged in to the wrong one. (Probably because I had just that day been fixing a problem with the list UI for that wrong list and made a mental screw up based on association and the fact that I still had a browser window opened to it).
I got that figured out when the real admin of the list logged in and approved one and cancelled the rest and the approved one came across the wire, which surprised me since I had not had the luck.
(continued below)
On Nov 18, 2011, at 12:30 AM, Mark Sapiro wrote:
The message is being held for some reason. Mailman's vette log will tell you why, and it should appear on the list's admindb interface.
This is what was confusing me since I was logged in to the wrong list's admin UI.
However, there was no vette log. That appears to get created by the action of the admin going through and canceling or approving already held messages, but does not show the original hold condition/reason.
There is a vette log after the real admin went in and cleared out all my test posts and approved her real one.
Now that I see what the issue was, things are OK. But the lack of logs had concerned me and I was not sure how to debug why they were not getting written as the permissions all looked fine. Hence my original confusion.
If you don't see the held message in the admindb interface, the web server is pointing at the wrong Mailman installation.
Or I am in the wrong list admindb interface ;-)
Thanks for your help! Chad
chad+mailman@shire.net wrote:
I had a successful mailman installation running on one server. Due to some HW issues on that server that we have not been able to address, the mailman installation was moved to a different, similar server. The qrunners all run, and the cgi stuff works for UI of the lists, but no messages are sent out. The MTA is exim.
When a mail comes in for a list, exim successfully delivers the mail to mailman. The message DOES appear in qfiles/in for a second or two before mailman grabs it. It then next shows up in data/heldmsg-LISTNAME-nnn.pck and is not sent out. This happens regardless of "emergency moderation" being sent, and if you go to the admin UI for the list, there are NO pending moderation requests showing.
The message is being held for some reason. Mailman's vette log will tell you why, and it should appear on the list's admindb interface.
logs/ shows nothing except when the qrunners start and stop (successfully).
If you don't see anything in Mailman's vette log, there is either a permissions issue in writing the logs or you are not looking at the correct logs.
If you don't see the held message in the admindb interface, the web server is pointing at the wrong Mailman installation.
check_db is a very minimal test. It only checks that config.pck* can be successfully unpickled.
Are you certain you are looking at the correct Mailman installation?
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Turns out this is an embarrassing case of user being an idiot. I was looking in the wrong list admin UI. There are two lists with similar names and for some reason I was logged in to the wrong one. (Probably because I had just that day been fixing a problem with the list UI for that wrong list and made a mental screw up based on association and the fact that I still had a browser window opened to it).
I got that figured out when the real admin of the list logged in and approved one and cancelled the rest and the approved one came across the wire, which surprised me since I had not had the luck.
(continued below)
On Nov 18, 2011, at 12:30 AM, Mark Sapiro wrote:
The message is being held for some reason. Mailman's vette log will tell you why, and it should appear on the list's admindb interface.
This is what was confusing me since I was logged in to the wrong list's admin UI.
However, there was no vette log. That appears to get created by the action of the admin going through and canceling or approving already held messages, but does not show the original hold condition/reason.
There is a vette log after the real admin went in and cleared out all my test posts and approved her real one.
Now that I see what the issue was, things are OK. But the lack of logs had concerned me and I was not sure how to debug why they were not getting written as the permissions all looked fine. Hence my original confusion.
If you don't see the held message in the admindb interface, the web server is pointing at the wrong Mailman installation.
Or I am in the wrong list admindb interface ;-)
Thanks for your help! Chad
participants (2)
-
chad+mailman＠shire.net -
Mark Sapiro