Mark Sapiro writes:
> Actually, there's more involved in the pipeline between the
> to_archive and to_outgoing handlers. The to-digest, to-usenet,
> after-delivery, acknowledge and dmarc handlers are all invoked
> between to_archive and to_outgoing
IIRC all of the shunted messages that Stephen looked at with qfiles
were those special digest messages (ie, message component empty,
pointer to lists/$LIST/something.mmdf in the msg_data component). So
something is going wrong in the to-digest handler.
I don't understand why the original .pck would disappear without
either leaving an error log or delivering. (Hmm, @Stephan, have you
looked at your "vette" log? it is a separate log in your mailman.cfg I
think.)
The number of .tmp files lying around bothers me. AFA grep CS, the
only place that can happen is in switchboard.py:136 in .enqueue:
with open(tmpfile, 'wb') as fp:
fp.write(msgsave)
pickle.dump(data, fp, protocol)
fp.flush()
os.fsync(fp.fileno())
os.rename(tmpfile, filename)
where `msgsave` is already a pickled object. So either pickle.dump is
choking on something in data (the metadata, which I believe is all
primitive Python data types), or something (OOM kill?) is happening at
the OS level. A crash in pickle.dump should leave an exception log
and backtrace in the logs.
AFAIK, Mailman does not clean up .tmp files at startup, right?
--
GNU Mailman consultant (installation, migration, customization)
Sirius Open Source https://www.siriusopensource.com/
Software systems consulting in Europe, North America, and Japan
_______________________________________________
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/FA427OB7WX33J27NVCYORERUUGZXEKYV/
This message sent to [email protected]
