As you had suggested, the in runner/queue was missing in action. Given
your insight about the limitations of mailman restart, I looked back
at the log from the time of the preceding mailman start, and found
that there was NOT a line such as:
in runner started.
in that instance! Watching the logs on each subsequent mailman start,
the good news is that the in runner/queue has been started each time;
the bad news is that slightly more than half of the time one or two
runners are NOT shown as starting. The other runners/queues sometimes
missing in action per the log file have been retry, task, nntp,
archive, and pipeline.
No errors are being recorded in the mailman log files. This is GNU
Mailman 3.3.8 via pip install mailman on Debian 5.10.179-1
(2023-05-12) running on a shared system where VMware gives this server
enough cycles that mailman start and mailman stop each consume from
20 minutes to an hour of wall clock time, so I do not issue those
commands recreationally, attempting to keep the system available for
users. What should I do to help understand the cause for these failures?
Would not it be helpful for this limitation of restart to be included in:
mailman restart --help
with a suggestion to use mailman stop and mailman start instead?
On 6/1/23 11:16, Mark Sapiro wrote:
When you issued a restart and the logs show runners restarting, did all the runners restart or was one or more missing.