On Tue, 05 Jun 2001 08:53:15 +0200, Sheldon Hearn wrote:
> Yes, several people have reported similar observations. The files
> suggest that Exim crashed in between writing the -D and -H files.
> Philip's last comment on the matter was that it's always possible that
> there's some bug in Exim causing this, but he hadn't found one. Obviously,
> system instabilities and platform-specific gotchas need to be ruled out
> first. He's away for a few weeks, so you'll have to be patient. :-)
Since several people have reported this, I'm posting a shell script that
administrators can use to test for the presence of these orphaned data
spool files in the meantime.
As Philip mentioned, a manual delivery attempt (using the -M
command-line option) should remove the files. For this reason, the
shell script prints message ID's instead of file names, so that it can
be called with:
/path/to/exim -M `/path/to/find_exim_orphans`
Ciao,
Sheldon.
#!/bin/sh
#
# find_exim_orphans:
#
# Find orphaned data spool files, which have no corresponding envelope
# spool files. These are the result of an unfortunately timed crash.
#
# Requires a POSIX shell.
#
spool=/var/spool/exim/input
for i in `find ${spool} -name '*-D'`; do
dir=${i%/*}
fnm=${i##*/}
mid=${fnm%-D}
if [ ! -e ${dir}/${mid}-H ]; then
# Confirm that the envelope file still exists to close a
# race condition that could result in false hits.
#
if [ -e ${dir}/${mid}-D ]; then
echo $mid
fi
fi
done
