Mark Sapiro writes:
On 2/6/25 04:53, Markus Grandpré wrote:
Unfortunately, I have not found any error message in the log files.
If you are using uWSGI, a harakiri timeout should be logged in uWSGI's log.
I think gunicorn logs to access.log and error.log in the Mailman logs directory. I would think it would log 500 level events, that indicates server trouble.
Regardless of whether a mass operation process runs without errors or continues to run despite an error, I find it hard that Postorius does not display the progress of such a mass operation in order to monitor the process, as mass operations with more than 1000 members are very time-consuming. Perhaps this could be changed in a future version of Postorius?
This is a reasonable request. The best place for such a request is https://gitlab.com/mailman/postorius/-/issues/new
It's reasonable, but for unsubscribe Postorius invokes the mass remove REST API. So to report progress there it would require new code in Mailman and mailmanclient to report progress, or Postorius could use an explicit loop over addresses as mass subscribe does -- which would be noticably slower, I suspect.
Periodic heavy use of mass operations is a common use case at universities. It's not uncommon for each term to see thousands of list averaging scores of subscriptions or unsubscriptions, with both number of lists and average roster size spike at academic year transitions when departmental and university-wide lists turn over. We should look at speeding up mass operations. I suspect internally Mailman is looping over individual addresses, probably creating a separate RDBMS transaction for each one. It should be possible to batch these, allowing the RDBMS to optimize its own table locking. Perhaps for the university use case it would make sense to even have Mailman multiplex these transactions across multiple lists being accessed at the same time.
Steve