On Fri, 17 Nov 2000, Graham Leggett wrote:
> I've just noticed a weird thing with v3.03 of Exim. There are a number
> of messages in the mailqueue that are undeliverable due to user quotas
> being exceeded. I increased the quota and told exim to -qff, and exim
> came back with a whole lot of error messages:
>
> 2000-11-17 11:25:20 13wAGt-0003qP-00 unable to update spool header file
> for 13wAGt-0003qP-00 after reading journal
That is worrying. I think it's the first time I've actually seen that
message. Although there have been lots of changes since 3.03, the way it
updates spool files has not changed for a very long time. However, since
3.03 there have been changes which make it log more information for
this kind of error.
The fact that it is reading a journal file means that there was some
kind of a crash previously when it tried to deliver this message.
Normally, journal files should not be left lying around. Maybe it failed
earlier to write the header file.
> Looking at the spool header file reveals that it has been trucated, the
> file is exactly 4 clusters in size.
Could you send me a sample, please? I'm a bit surprised by this, because
the message "unable to update spool header file" is logged when Exim is
trying to write to a temporary file which it will later rename as a new
header file. If it gets this error, it should abort without attempting
the rename, thereby leaving the old file in place.
> More importantly though - if I delete these truncated spool header files
> from the msglog directory, will it still be possible to deliver the
> messages?
I presume you mean the input directory, not the msglog directory? The
answer is "no". If you delete the header file (the one ending in -H),
you are essentially throwing away the message.
--
Philip Hazel University of Cambridge Computing Service,
ph10@??? Cambridge, England. Phone: +44 1223 334714.
