[Mailman-Users] Archiving is broken

Mark Sapiro mark at msapiro.net
Thu Aug 21 20:07:01 CEST 2008

Mark Heer wrote:
> The bigger issue is the complete lack of archiving.   even public 
> lists which used to archive just fine are not doing anything.  You 
> may recall that you provided the syntax for the external 
> prvate/public archive entry I placed in the mmcfg.py file.  It worked
>  perfeclty for over a month and simply stopped workin 8/12.  Can you 
> offer some debug advice or some way of unwedging the archive routine?
>  I feel really stuck.  I have been archiving to our old hypermail 
> setup until I can unravel this problem. As I mentioned, the only 
> change on 8/12 was to change 1 list to yearly vs monthly after which 
> I recreated the archive from a flat file (mm mbos with hypermail flat
>  file catted to the end). could this be a factor?

And in another message

> Sorry, I should clarify our installation -  we have 2 mail servers
> handling the mail exchanges and 1 server handling the admin functions
> all are running mailman.  When the mail servers send to the external
> archive they send to our admin mailman server which accepts the piped
> mail and runs the /bin/arch script populating the pipermail archive.
> The key on the admin machine receives the piped mail and does the
> right thing - all until lat week.  I ran the /bin/arch to re-create
> the archive as a yearly archive on the receiving side or - admin
> machine, not on the mail exchangers.

It's possible that your rebuilding of the archive caused permissions
issues if you didn't run bin/arch as the mailman user. Since this is all
you did, it seems worth investigating.

As far as debugging the 'external' archiving from the mail machines to
the admin machine is concerned, did you try running the command manually
as I suggested in a prior reply.

If the external archiver fails, there should be a "external archiver
non-zero exit status: %d" message in Mailman's error log on the mail
machine, but more likely, the ssh command succeeds and the failure is in
the script on the admin machine which at best you might see as output if
you run the ssh by hand.

If your script on the admin machine is like the one at
you could try changing

  bin/arch $1 $f

or whatever similar command you have to something like

  bin/arch $1 $f >>/path/to/log/file 2>>/path/to/log/error

to see what the command is actually doing.

Mark Sapiro <mark at msapiro.net>        The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan

More information about the Mailman-Users mailing list