Mark writes:
# tail -f /opt/mailman/web/logs/mailmanweb.log
File "/opt/mailman/venv/lib/python3.11/site-packages/mailmanclient/restbase/connection.py", line 160, in call raise HTTPError(params.get('url'), response.status_code, urllib.error.HTTPError: HTTP Error 500: {"title": "500 Internal Server Error"} ERROR 2024-01-24 05:41:46,333 51799 django.request Internal Server Error: /postorius/lists/testing.example.com/
I don't recall seeing this one before, maybe Mark S has some idea.
Try running all the system initializations with "mailman info" and "mailman conf". This often will elicit errors if the system is messed up. More likely to get this error would be "mailman withlist $LIST" (maybe you need an '-l' option to specify the list, I forget). If that doesn't elicit the error, then check that Mailman's runners are running with ps. Since it's Debian, I guess they should be running as the 'list' user. Are Mailman's files and directories owned by 'list' or sometimes 'www-data' for log files?
The log is saying that when Postorius tried to look up that list, it tried to call out to Mailman core via HTTP to the API to get the information and that access failed with HTTP status 500. I think the actual error is likely to be reported in mailman.log (or it might be in error.log, "grep '05:41:46' *.log" in Mailman's log directory will probably find it). I'm pretty sure there will be relevant log entries, probably a matching traceback.
You might also try grepping in your SQL DB logs for that timestamp.
And the Mailman log is a mystery to me,
It's hard to get good exception reporting when you have multiple layers in the stack, and some of them are separated by TCP/IP connections. You'll have to correlate across logs by timestamp.
and no error is reported in the Nginx log ...
Right, this is happening far far away from nginx, much farther down the stack.
Steve