On Thu, 20 Dec 2001, Reena John wrote:
> The only pattern I can see for the junk, orphan -D files that is filling up
> our spool is size. I can categorize the -D files into three types based
> upon their size (about the only common feature) from looking through the
> input (spool) directory from Nov 16 to date.
>
> 1. 147456 bytes - 1526 "-D" files between Dec 7 - Dec 20.
> 2. 163840 bytes - 436 "-D" files between Dec 18 - Dec 20.
> 3. 32768 bytes - 4 "-D" files between Dec 18- 19
163840 is 32768 times 5. 147456 isn't a multiple of 32768, but it is a
multiple of 8192. So they are all multiples of 8192. My suspicion is
that these numbers are multiples of the blocksize of your file system.
That suggests that the file is not getting closed properly, and probably
also not even written properly.
> The mails are coming from different ip addresses (can be made out amidst
> the junk in the -D file). Some come from the same IP address: 150 odd
> coming from the same address on Dec 18 of which I wrote about in my
> previous mail (see below).
I wouln't trust the data in the file. Again a guess, but I suspect the
contents are random blocks of memory, or possibly just random blocks of
disk left over from some other file.
> Its strange but there is header information in the 'junk' of the orphan -D
> files.
An artefact of unwritten memory blocks being written, I suspect. (I may
be wrong, of course.)
> Sorry about the misquote... the error message is:
> 2001-12-20 09:58:21 Connection from x.x.x.x refused: too many connections
When that happens, Exim doesn't even start to receive a message from
that IP address. It gives an error response at the initial connection.
So it should never get anywhere near trying to create a -D file.
I'm not sure what to do next. If you turn on log_smtp_connections your
log will fill up with connection and disconnection messages. If Exim
crashes while reading a message and creating a -D file, the evidence
should be a connection log line without a corresponding disconnection,
but a script would need to be written to detect that - and I'm not sure
we would learn much more anyway.
Puzzled...
--
Philip Hazel University of Cambridge Computing Service,
ph10@??? Cambridge, England. Phone: +44 1223 334714.
