Author: W B Hacker Date: To: exim users Subject: Re: [exim] Silly situation - reprocess mail in queue
Marcin Krol wrote: > W B Hacker wrote:
>> - a set of 'characteristics' or administrative information, including
>> acl_m variables, and whether it has delivered the 'nth' copy of a
>> mult-recipient message, etc.
>>
>> Should be safe to do a CP -Rp of the whole queue structure.
>
> Done. Now what?
>
>> 'How to' best feed them back into the food chain can be discussed once
>> you are sure you still *have* them..
>
> You certainly have my attention.
>
> Regards,
> mk
>
>
I'm presuming you haven't had the beast shut-down all this time, AND
that Exim sees the failure as earnign a 'retry', ELSE it is too late
once 'bounced'.
so...
- Check logs and recipient inboxes to see if Exim *was* able to complete
balked deliveries once all was set back 'right'.
You might see any of:
- ALL balked deliveries were picked-up where paused and delivered as
intended.
= no action required
- NO balked deliveries were 'fixed up'.
= manual re-delivery needed. Maybe. These might be catching up due to
ordinary 'retry' as we speak.
- Some were, some were not (depending on at what point the change
'caught' them).
Ditto - see if 'retry time not reached...' is being logged, meaning Exim
is still workign at catching up.
= deeper analysis required, as there may also be some 'missing'
+++++
At this point, one tends to cheat.
Having in hand a 'safety copy' I'd manually fire-off a series of
queue-runners about 30 seconds apart, then see what went where, and if
there is really anything further that needs to be done.
With luck, there isn't. Exim is very good at gracious recovery.
Try:
exim -obd -q30s
Check to see if that empties /var/spool/exim/input
Then restart Exim so as to utilize your 'usual' queue run settings.
