[Mailman-Users] Errors with > 1000 members.

[Harald Meland]

[Clark Evans]

> As I was adding users to a list (probably around a thousand?), I got
> the error at the bottom.

I have experimented somewhat with adding lots of users to Mailman
lists, and found that if the mass subscribe process takes to long, the
CGI script is killed off by the server (and leaves me with a Netscape
popup window saying "Document contained no data").

Apparently, for Apache, the appropriate config option is "Timeout" --
which defaults to 300 (= 5 minutes).

If the server kills off the CGI script at a bad time -- in the middle
of saving the list config db -- you'll experience problems like you
describe.

The solution is to replace the list's corrupted config.db with the
previous version, called config.db.last.

Possible solutions I can think of:

 * Speeding up the mass subscribe processing:

   Currently, when adding lots of members from the web interface, the
   list config db is saved after each addition, and then finally once
   more at the end.
   
   I'm considering changing this so that only the "final" save is
   done.  That would speed up the mass subscription processing
   considerably -- and thus the CGI will be more likely to finish
   within "Timeout" -- and also reduce the risk of the script being
   killed off at a bad time, as only _one_ config save will be
   performed.
   
   However, such a change will also mean that _if_ the CGI is killed
   off, _none_ of the intended list changes have been saved.

 * Make sure the CGI script _isn't_ killed:

   If the Mailman CGI scripts are changed to ignore SIGTERM signals,
   would the problem go away?  I don't know enough about CGI scripting
   to say for sure, but my guess would be that _some_ server kills off
   timed-out processes with SIGKILL.

   And, even if the script isn't killed, the server will still close
   the connection on timeout -- leaving me with "The document
   contained no data" popup windows.

If anyone have other, better ways of solving this, let me know...

-- 
Harald