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. More if you need it... Bill -- ## List details at http://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
