I have been battling a weird archives issue with our GNU Mailman mailing list server. We have some lists that archive properly when e-mail is sent to them. We have other lists where the e-mail is delivered but does not show up in the archives. We also have lists where e-mail sent to them disappears and is never heard from again. I have been hassling with this permissions issue literally for years now. I picked the baton up again today and decided to try to bring this one home. First I started in the mailman error logs:
Jul 26 12:25:43 2010 (2755) Uncaught runner exception: [Errno 13] Permission denied: ‘/var/lib/mailman/archives/private/listname/index.html’Jul 26 12:25:43 2010 (2755) Traceback (most recent call last):
File “/usr/lib/mailman/Mailman/Queue/Runner.py”, line 112, in _oneloop
File “/usr/lib/mailman/Mailman/Queue/Runner.py”, line 170, in _onefile
keepqueued = self._dispose(mlist, msg, msgdata)
File “/usr/lib/mailman/Mailman/Queue/ArchRunner.py”, line 73, in _dispose
File “/usr/lib/mailman/Mailman/Archiver/Archiver.py”, line 217, in ArchiveMail
File “/usr/lib/mailman/Mailman/Archiver/pipermail.py”, line 324, in close
File “/usr/lib/mailman/Mailman/Archiver/HyperArch.py”, line 1094, in write_TOC
toc = open(os.path.join(self.basedir, ‘index.html’), ‘w’)
IOError: [Errno 13] Permission denied: ‘/var/lib/mailman/archives/private/listname/index.html’
Jul 26 12:25:43 2010 (2755) SHUNTING: 1280155615.876646+a19c8dce602a83897d29592d36d618fc80195ec7
I didn’t remember seeing this particular error message before (of course I didn’t write down the old ones) so I started over again with fresh eyes. After googling for a long time I ran across this nugget
>>I ran several times check_perms -f and it says all is fixed.
> check_perms is lying (actually, there are many files, as opposed to
> directories, that check_perms doesn’t check). The above file and all
> files in /var/lib/mailman/archives/private/ excluding those in
> /var/lib/mailman/archives/private/*/database/ need to be group
> Once you fix these permissions, you could run bin/unshunt to add the
> shunted messages to the archive, but there is an issue in that the
> messages have been successfully added to
> /var/lib/mailman/archives/private/mylist.mbox/mylist.mbox, and
> unshunting will add them again.
> Rather than trying to fix archive permissions, I suggest you verify
> that /var/lib/mailman/archives/private/mylist.mbox/mylist.mbox
> contains all the lists posts from inception to date, and mayby verify
> there are no stray “From ” lines in message bodies with bin/cleanarch,
> and then stop Mailman and rebuild the archive with
> bin/arch –wipe listname
> and then start Mailman. This way, the pipermail archive will be
> completely rebuilt with correct permissions.
> This is one reason why I always recommend when moving lists to just
> move the LISTNAME.mbox/LISTNAME.mbox file and build the archive on the
> new machine with bin/arch.
> Note if you do this, remove the shunted messages from qfiles/shunt/ so
> they don’t accidently get unshunted in the future.
What? The check_perms utility doesn’t fix all of the needed permissions in order for mailman to run properly? Why won’t it complain when the daemon starts up then? Why won’t it at least say that some of the permissions have been correct but not all of them? I’ve been running this mailman installation for several years now and I (and all my buddies who also run mailman) have always held up check_perms as the gold standard for making sure that mailman works properly. I wish I had known about this a few weeks ago when I was moving hundreds of gigabytes of files from one server to another. The bit about moving lists would have saved me (and my end users) a lot of time.