On 9/19/19 2:22 AM, Manos Pitsidianakis wrote:
Thank you again for your reply, Mark.
Στις 2019-09-18 21:53, Mark Sapiro έγραψε:
What are these entries?
I have these log entries, are these what you were referring to?
No. You referred to "shunted" mails. I assumed that mail was winding up in the shunt queue, but this is apparently not the case.
The "Cannot connect to SMTP server" log message should not occur immediately on startup unless there are queued messages. That log message should only occur on an attempt to actually send a message.
I think the problematic e-mails that cause this issue are stuck on the outgoing queue. Right now there are 2 pck files and one .bak in var/queue/out changing filenames repeatedly.
What is happening is you have three messages in the out queue which are problematic. When Mailman or the out runner is restarted, for some reason the attempt to send these triggers the "Cannot connect to SMTP server" issue which is logged only once.
Here's what happens:
The oldest .pck file in the out queue gets picked up by the out runner and renamed to a .bak.
The runner attempts to send the message and gets a socket.error exception so it requeues the message to be tried again. This removes the .bak and creates a new .pck.
This process continues so the files keep getting renamed.
I suggest you stop Mailman, and move the three files out of the out/ queue, and then restart Mailman.
This should stop the out runner from "spinning" on these messages. Then you can examine the files with Mailman's 'bin/mailman qfile' command and see if you can identify something in the recipients list or other metadata that might be causing this.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan