On 12/31/20 2:49 AM, Andreas Barth wrote:
Hi together,
as I found some mails in queue/shunt, I thought who should be running them.
See below.
On my (standard debian) reference system, there are no cron entries for mailman3 but only for mailman3-web.
The crons for Mailman core are discussed at <https://docs.mailman3.org/en/latest/config-core.html#configuring-cron-jobs>.
Looking in the source code, there is a ./cron/crontab.in.in however references to scripts in port_me/ directory.
That's all old Mailman 2.1 stuff. ignore it.
Should I (still) install (parts of) the crontab? Or are these functions handled elsewhere?
Again, see <https://docs.mailman3.org/en/latest/config-core.html#configuring-cron-jobs>.
Also, who picks up mails in queue/shunt? Or are they lost somehow?
When processing of a message in Core throws an uncaught exception, the
error is logged with a traceback in var/logs/mailman.log and the
message's queue entry is saved in the /var/queue/shunt/ queue. These
messages can be retried via the mailman unshunt command, but unless
the underlying cause has been fixed, they will throw the same exception
and be shunted again.
Each shunted message requires manual inspection of the
var/logs/mailman.log entry and possibly examination of the message via
mailman qfile /var/queue/shunt/....pck.
Some of these are spam messages which are somehow defective causing the exception, and these can just be manually removed from the shunt queue.
I've seen a couple that are transient errors[1] that can just be successfully unshunted.
The rest require some underlying issue to be fixed before they can be successfully unshunted.
[1] In particular, I've seen an apparent race condition in building the list of recipients where we try to determine the delivery status for a member that is no longer a member.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan