Liam Reilly wrote:
Stephen J. Turnbull wrote:
Here is an example error from the log for unsubscribe all operation. Which log is this? I would guess it's the mailmanweb.log. [2025-12-15 15:41:02 +0000] [1022464] [ERROR] Error handling request /mailman3/lists/uclucu-members.ucl.ac.uk/unsubscribe_all Traceback (most recent call last): File "/data/mailman/venv/lib64/python3.12/site-packages/gunicorn/workers/sync.py", line 134, in handle self.handle_request(listener, req, client, addr) This is the front-end gunicorn WSGI server, handling a request for Postorius. File "/data/mailman/venv/lib64/python3.12/site-packages/mailmanclient/restobjects/mailinglist.py", line 519, in unsubscribe response, json = self._connection.call(path, data, method='DELETE') ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ This is mailman client translating to the REST API. File "/usr/lib64/python3.12/socket.py", line 720, in readinto return self._sock.recv_into(b) ^^^^^^^^^^^^^^^^^^^^^^^ This is the Python socket library actually talking to the REST API of Mailman core. An unspecified error occurs in the C code. It is not handled. File "/data/mailman/venv/lib64/python3.12/site-packages/gunicorn/workers/base.py", line 204, in handle_abort sys.exit(1) SystemExit: 1 This is the "Something's wrong, hope you have a clue 'cause I don't" last line of defense error handler. My guess is that it's a timeout on a socket. I think you should also see log messages and a traceback in the mailman.log. The timeout for the mailmanweb gunicorn is configured in the gunicorn conf file, usually in /etc/mailman3. This is relatively short (I Reilly, Liam writes: think my installation is default at 120 seconds). The timeout for the REST API gunicorn is in site-packages/mailman/config/gunicorn.cfg. This is long (360 seconds) so if my conjecture about timeout is correct it's the mailmanweb gunicorn that's timing out. If you need to change this one, you may be able to simply put "timeout: 360" in the [webservice] section of your mailman.cfg file, but if that doesn't work you can copy gunicorn.cfg to /etc/mailman3/rest-wsgi.cfg, change the timeout in it, and add "configuration: /etc/mailman3/rest-wsgi.cfg" to the [webservice] section of mailman.cfg. GNU Mailman consultant (installation, migration, customization) Sirius Open Source https://www.siriusopensource.com/ Software systems consulting in Europe, North America, and Japan As always, thank you for your prompt replies Stephen. The entries are from error.log and are all I could find when grepping for the list name. I'll check the other logs for anything else and also try increasing the timeout config as you've suggested to see if it helps.
After some experimentation, I think I've got a working configuration.
Setting the timeout in /etc/mailman3/rest-wsgi.cfg did not seem to work properly. In the end I had to modify the systemd unit file for mailmanweb, adding a --timeout to the ExecStart line:
ExecStart=/opt/mailman/venv/bin/gunicorn -c /opt/mailman/mm/gunicorn.conf.py --timeout 360 mailman_web.wsgi:application
Mass operations now failed with a different "proxy error" after 60s instead of "internal server error" after 30s.
I then added "ProxyTimeout 300" to /etc/httpd/conf.d/mailman3.conf to increase that timeout.
Testing this I can now mass subscribe 4500 members in ~100s and mass remove them again in ~150s without any errors.
I wonder if there's any way to reduce the time it takes to process such operations? More workers? I have been testing with 4 webservice workers.