Am 09.03.22 um 15:04 schrieb Jeremy Harris via Exim-users: > On 17/02/2022 06:48, Martin Waschbüsch via Exim-users wrote:
>> Am 17.02.22 um 00:38 schrieb Michael Tratz via Exim-users:
>>> No restarting the daemon doesn’t do anything. The only solution which
>>> works is to kill all exim processes and then restart the daemon.
>>> exim will run through the queue and try again. The same messages
>>> which caused the delivery process to be stuck will again cause a
>>> stuck process. Once the retry rules have been exhausted (5 days) the
>>> message will be removed from the queue after a new restart and
>>> killing all exim processes. Otherwise those messages will just stick
>>> around. I had some which were in the queue for 20+ days until I
>>> noticed that issue.
>>
>> FWIW, reading through the patches Jeremy thought might not yet be
>> applied for the FreeBSD exim version we are using, I think he did not
>> suggest that restarting would 'fix' messages already stuck.
>> Rather, if the issue were related to the patches / issues he
>> mentioned, restarting the daemon might prevent messages from getting
>> stuck in the first place.
>
> Precisely.
>
> Any news on the occurrence with a periodic restart?
Restarting made no difference at all (I sent a HUP every 15 minutes).
> Commit c57309a504 might also be relevant. Has FreeBSD picked that one up? Not yet, it seems. I'll try to upgrade one of the relays to a version of
exim that includes this and see if that helps.
