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?ref_type=heads#L182-L199
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 <[email protected]> The highway is for gamblers,
San Francisco Bay Area, California better use your sense - B. Dylan
_______________________________________________
Mailman-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/
Archived at:
https://lists.mailman3.org/archives/list/[email protected]/message/ONWPQZTOPHCVJ6DWAUCN5Y6MBHU7GBLD/
This message sent to [email protected]
