can't access /admin or /admindb/ for one of my lists, other lists work fine
Hi Folks
I've googled the archives and poked around as much as I could, but cannot find the answer to my problem, so I figured I'd post to the list to see if anyone had any ideas.
We had a very large number of moderation messages for one of our lists (33,000+) so I went to mailman/data and manually rm'ed them (them being heldmsg-listname-*.pck). I've done this in the past without any problems but for some reason this time it seems to have possibly screwed up my list config such that I can no longer access the admin or admindb URLs. The request is sent but the browser times out waiting for a response.
We're running maybe a dozen other lists on the same machine, and there's absolutely no problems accessing those lists' /admin and /admindb URLs. I've tried restarting mailman (it's worth mentioning that mailmanctl stop doesnt actually stop mailman and it has to be manually killed and restarted with the -s option) and apache, but nothing helps. It's also worth mentioning that there don't seem to be any problems with /options/listname. I've run check_perm and check_db on the list specifically, but there's no reported problems.
Does anyone have any suggestions as to what might be wrong here, or of any other diagnostics I could avail myself of?
tia,
w
wallace winfrey wrote:
We had a very large number of moderation messages for one of our lists (33,000+) so I went to mailman/data and manually rm'ed them (them being heldmsg-listname-*.pck).
That's part of the problem. When you just rm the heldmsg-listname-nnnn.pck, you are only removing the message, you are not removing the entries about the message from the mailman/lists/listname/request.pck and mailman/lists/listname/pending.pck files.
You should use
bin/discard data/heldmsg-listname-*.pck
or with 33,000 messages
bin/discard --quiet data/heldmsg-listname-*.pck
to supress the 33,000 "Discarded held msg ..." reports.
I've done this in the past without any problems but for some reason this time it seems to have possibly screwed up my list config such that I can no longer access the admin or admindb URLs. The request is sent but the browser times out waiting for a response.
I'm not sure what's going on with the admin page. The list may be locked. The admindb page is still looking at all those entries in requests.pck.
We're running maybe a dozen other lists on the same machine, and there's absolutely no problems accessing those lists' /admin and /admindb URLs. I've tried restarting mailman (it's worth mentioning that mailmanctl stop doesnt actually stop mailman and it has to be manually killed and restarted with the -s option) and apache, but nothing helps. It's also worth mentioning that there don't seem to be any problems with /options/listname. I've run check_perm and check_db on the list specifically, but there's no reported problems.
Does anyone have any suggestions as to what might be wrong here, or of any other diagnostics I could avail myself of?
As I suggested, you can look at mailman/locks/ to see if there might be a stale lock for the list and if so, remove it. Can you access an actual member's options page, or just the options login page? If the former, then the list probably isn't locked. In either case, this shows the config.pck is OK.
Assuming you're not concerned about losing possible other request like subscription approvals, etc. you can try just moving requests.pck out of the lists/listname/ directory. You may have to do the same with pending.pck. Mailman will create new 'empty' ones when you go to the admindb page.
At 6:38 PM -0700 9/29/06, Mark Sapiro wrote:
or with 33,000 messages
bin/discard --quiet data/heldmsg-listname-*.pck
to supress the 33,000 "Discarded held msg ..." reports.
With 33,000 messages, I imagine that command-line wildcard expansion won't work. You may have to do something like:
find /usr/local/mailman/data/heldmsg-listname-\*.pck -print |
xargs bin/discard --quiet
All as one line, of course.
Mark Sapiro wrote:
You should use
bin/discard data/heldmsg-listname-*.pck
or with 33,000 messages
bin/discard --quiet data/heldmsg-listname-*.pck
to supress the 33,000 "Discarded held msg ..." reports.
OK, thanks for the reminder. I think I remember seeing something about this in the docs, now that I'm thinking about it. Duh.
As I suggested, you can look at mailman/locks/ to see if there might be a stale lock for the list and if so, remove it. Can you access an actual member's options page, or just the options login page? If the former, then the list probably isn't locked. In either case, this shows the config.pck is OK.
OK, great. Yeah, it's the former.
Assuming you're not concerned about losing possible other request like subscription approvals, etc. you can try just moving requests.pck out of the lists/listname/ directory. You may have to do the same with pending.pck. Mailman will create new 'empty' ones when you go to the admindb page.
Subscriptions aren't moderated, so no big deal. However, I noticed that posting to the list seems to have stopped working since I removed all those files. Is this a side-effect of "corrupting" the pending.pck and/or config.pck files And would removing them to create new empty ones "fix" this problem?
cheers
w
wallace winfrey wrote:
I've tried restarting mailman (it's worth mentioning that mailmanctl stop doesnt actually stop mailman and it has to be manually killed and restarted with the -s option) and apache, but nothing helps.
After you do mailmanctl stop, what's still running. Presumably, still mailmanctl, but which if any qrunners? Also, what's in Mailman's qrunner log? Also, did you manually kill *all* Mailman processes before starting again? See http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq04.068.htp.
Mark Sapiro wrote:
After you do mailmanctl stop, what's still running. Presumably, still mailmanctl, but which if any qrunners? Also, what's in Mailman's qrunner log? Also, did you manually kill *all* Mailman processes before starting again? See http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq04.068.htp.
mailman 23733 0.0 0.7 18692 16056 ? S 17:20 0:07 /usr/bin/python /usr/local/mailman/bin/qrunner --runner=OutgoingRunner:0:1 -s
I *do* manually kill them all off before starting again.
cheers
w
wallace winfrey wrote:
Assuming you're not concerned about losing possible other request like subscription approvals, etc. you can try just moving requests.pck out of the lists/listname/ directory. You may have to do the same with pending.pck. Mailman will create new 'empty' ones when you go to the admindb page.
Subscriptions aren't moderated, so no big deal. However, I noticed that posting to the list seems to have stopped working since I removed all those files. Is this a side-effect of "corrupting" the pending.pck and/or config.pck files And would removing them to create new empty ones "fix" this problem?
It looks like a bunch of messages in the meantime have popped up in the mailman/data directory; presumably some of them are posts from subscribers that didn't make it out to the list ? Any idea on how to fix this?
(I'm still wondering why I didn't shoot myself in the foot the last time I did this).
thx
w
wallace winfrey wrote:
Mark Sapiro wrote:
As I suggested, you can look at mailman/locks/ to see if there might be a stale lock for the list and if so, remove it. Can you access an actual member's options page, or just the options login page? If the former, then the list probably isn't locked. In either case, this shows the config.pck is OK.
OK, great. Yeah, it's the former.
On second thought I'm not sure that getting the user's options tries to lock the list. It may only lock when you "Submit My Changes".
Assuming you're not concerned about losing possible other request like subscription approvals, etc. you can try just moving requests.pck out of the lists/listname/ directory. You may have to do the same with pending.pck. Mailman will create new 'empty' ones when you go to the admindb page.
Subscriptions aren't moderated, so no big deal. However, I noticed that posting to the list seems to have stopped working since I removed all those files. Is this a side-effect of "corrupting" the pending.pck and/or config.pck files And would removing them to create new empty ones "fix" this problem?
Hard to say without knowing the cause. I would investigate the locks.
wallace winfrey wrote:
It looks like a bunch of messages in the meantime have popped up in the mailman/data directory; presumably some of them are posts from subscribers that didn't make it out to the list ? Any idea on how to fix this?
They are held messages, so mail is getting that far which is good.
(I'm still wondering why I didn't shoot myself in the foot the last time I did this).
Removing (rm) a data/heldmsg... file doesn't cause a problem per se, but when there are 33,000 of them it creates a huge amount of work for the admindb script as it goes through the requests.pck, finds a held message, reports it in the HTML it's creating, etc. and then ultimately tries to do something with the message only to find it's not there.
The basic problem is not that you rm'd the data/heldmsg files; it's that there were 33,000 requests, and you didn't delete them.
participants (3)
-
Brad Knowles -
Mark Sapiro -
wallace winfrey