On 2007-06-01 at 21:28 -0700, Brian Friday wrote: > After a hardware failure I find our system had a number of in process
> messages that I rescued from the /var/spool/exim/input directory from
> a server and hardware which has ceased to function.
>
> What I am left with now is the quandry of how to take these rescued
> messages and push them back into exim or have exim pick them up and
> deliver them. A run of "mailq" returns the "spool file error" with
> the size of the message.
Exim embeds a timestamp in part of the filename, so provided that both
the old and the new servers had/have synchronised clocks, you can just
put the files back in the spool whilst Exim is not running any
queue-runners. Easiest way is to shut Exim down, but if you can't do
that, then:
* if you start "exim -bd -qTIME" then restart it without the -qTIME
* if you run queue-runners from cron, disable that
This way, once any extant queue-runners finish, Exim will only take
messages out of the spool if it's part of immediate delivery based on
when it started, or if it's a message which was previously "known" to
the new Exim install and recorded in a wait database to be delivered
down the same connection as another message. If this leaves you
nervous, then temporarily set queue_only true and queue_only_override
false in the global config section.
Do check that either both or neither of the installs are using
split_spool_directory; if the old install wasn't but the new one is then
you'll need to put each in the right sub-directory; it's easy enough,
see the split_spool_directory documentation in spec.txt.
Alternatively, if you believe that every one of the recovered messages
can be quickly delivered to the destination (they just need to be
squirted out to a mail-hub) then use a custom config which sets
spool_directory appropriately.
