On Fri, 1 Oct 1999, John Horne wrote:
> The file server seemed to be sending the message back to the
> mailhub - but no loop was detected.
Presumably because it wasn't sending the message back - it was wrapping
it in some new message. In doing so it was generating an automatic
response to a bounce message, which is against the rules in the RFCs,
precisely to avoid this kind of thing. Rap its knuckles!
> I tried to look at the logs files whilst this was going on, and running
> exiwhat. It showed that the exim process in question was 'tidying up
> after delivery' (can't be sure of the exact words).
That should be a very short phase when all is well. It involves updating
the retry database if necessary, and then deleting the message files. If
you see a lot of messages in this state, something is odd.
> The mailhub is a Sun Ultra 1/170, 64MB main memory with a 2GB mail spool
> space and (usually) about 190MB swap.
Have you upgraded this system since last year? Which OS is it running?
We had a problem when we first tried Solaris 2.6 because it had a bug
that made file deletion run like a blocked drain. It was cured by adding
this to /etc/system:
* ncsize hash table broken on large memory systems under Solaris 2.6
set ncsize=17500
but with only 64MB [*] I don't think that is relevant.
> Anyone any suggestions as to what exim was doing, and what we could do to
> avoid it again? As said we have had no problems in the past with these and
> larger lists on the same hardware.
... but what about the software?
---------------
[*] I can hardly believe I said that. I can remember when 4MB was a
*huge* amount of memory...
--
Philip Hazel University of Cambridge Computing Service,
ph10@??? Cambridge, England. Phone: +44 1223 334714.
