The Mailman Frequently Asked Questions
1. If from the web you get "document contains no data", or if mail isn't getting delivered, or if you see "Premature end of script headers", or if you see "Mailman CGI error!!!"
The most likely cause of this is that the GID that is compiled into the C wrappers does not match the GID that your Web server invokes CGI scripts with. Note that a similar error could occur if your mail system invokes filter programs under a GID that does not match the one compiled into the C mail wrapper.

To fix this you will need to re-configure Mailman using the --with-cgi-gid and --with-mail-gid options. See INSTALL for details. These errors are logged to syslog and they do not show up in the Mailman log files. Problems with the CGI wrapper do get reported in the Web browser though, and include the expected GID, so that should help a lot. You may want to have syslog running and configured to log the mail.error log class somewhere; on Solaris systems, the line 

          mail.debug                /var/log/syslog
causes the messages to go to them in /var/log/syslog, for example. (The distributed syslog.conf forwards the message to the loghost, when present. See the syslog man page for more details.) If your system is set like this, and you get a failure trying to visit the mailman/listinfo web page, and it's due to a UID or GID mismatch, then you should get an entry at the end of /var/log/syslog identifying the expected and received values.
2. If the web pages hang...
CERN Web servers might leave Python processes running, and in some cases might hang the CGI completely. In that case, switch to Apache.
3. Check ~mailman/logs/error periodically...
Many of the scripts have their stderr logged to ~mailman/logs/error, and some of the modules write caught errors there, as well, so you should check there at least occasionally to look for bugs in the code and problems in your setup.

One thing that is not caught by stderr hook is syntax errors, but any of these should have been caught in the installation phase, which byte-compiles all .py files in the distribution. There may be syntax errors lurking if you hacked the code, or in the scripts that are not modules.

You can always use the Python module compile or compileall to force byte compilation of a file, or just fire up the Python interpreter and try importing the module!

4. Other debugging aids
If you get exceptions in the log and/or Web pages, and these are complaining that files could not be opened, you might like to see which files Mailman is trying to open!

In Python 1.5.2, this will be a standard part of the exception message. In Python 1.5.1 the best you can do is to comment out the code in $prefix/scripts/driver where it is redefining the built-in open() function. This simulates what Python 1.5.2 will do when it raises an IOError exception, however this only works for open(). While this is the most common case, Python 1.5.2 will handle many other cases where files are unsuccessfully referenced.

5. Why doesn't the archive link work?
Have any messages been posted to the list? This is a known buglet; the archive link doesn't work until at least one message has been posted.
6. Okay, the archive link works, but I can't access the public archives.
If you are using Apache, you must make sure that FollowSymLinks is enabled for the path to the public archives. Note that the actual archives always reside in the private tree, and only when archives are public, is the symlink followed. See this archive message for more details:

http://www.python.org/pipermail/mailman-users/1998-November/000173.html

7. Still having problems? Running on Linux?
See the file README.LINUX in the distribution.
8. I want to get rid of some messages in my archive. How do I do this?
David Rocher posts the following recipe: 

     . remove $prefix/archives/private/listname
     . edit $prefix/archives/private/listname.mbox/listname.mbox [optional]
     . run $prefix/bin/arch listname 
	   $prefix/archives/private/listname.mbox/listname.mbox