Philip Hazel wrote:
> > 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.
I found the source of the problem - a quota had been set by accident on
the "mail" user, which caused the system to behave as if it had run out
of space. I think it's possible that Exim isn't handling the case when
the mailqueue gets full, or perhaps the behavior of the system with a
full mailqueue is different when the disk is really full, compared to
when a quota restriction kicks in.
> 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.
I think this behaviour is working, because I haven't noticed any
corruption in the input directory. It's just the msglog directory where
I noticed truncation of the files.
Regards,
Graham
--
-----------------------------------------
minfrin@??? "There's a moon
over Bourbon Street
tonight..."
