On 8/4/25 00:21, Krinetzki, Stephan wrote:
And for every one of those shunted messages there should be an exception with traceback logged in mailman.log. Those tracebacks should be helpful.
If there were any. Maybe the "debug" level should be "info". But for which logs?
The standard logging levels from lowest to highest are
debug info warning error critical
Whatever level is set for a log results in all messages of that level or higher being logged. I.e. if the log's level is debug, all messages for that log of any level should be logged.
For every shunted message, a message like
SHUNTING: <file name without the .pck extention>
preceded by the exception and traceback is logged to error.log with
level error. See
https://gitlab.com/mailman/mailman/-/blob/master/src/mailman/core/runner.py?...
Maybe the restart at night after the lograte maybe the issue.
As I said before, blindly restarting Mailman is a bad idea. On servers that I maintain, I always verify that all queues are empty before stopping or restarting Mailman. If necessary, I'll kill the incoming runner and wait for the out queue to empty and then stop mailman. If you want to do this daily, you could automate that., e.g.
if queues empty:
restart Mailman
else:
when in queue is empty, sigterm incoming runner
when out queue is empty, stop Mailman
when Mailman stopped, start Mailman
The stop/start is needed because a simple restart at that point won't start the sigtermed incoming runner.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan