On Tue, May 21, 2002 at 10:09:26AM -0700, Keith Smith wrote:
> Not to sound stupid, but this smells like a permission problem, or a
> path issue.
I doubt this is the case since the fault occurred only 80% of the time. I would
expect a 100% failure rate if it was a permissions problem.
>Did you double check that exim is running as the same uid/gid as on 3.12? (I
Indeed, yes.
>run mine as mail.mail) Perhaps a directory perm in a spool dir. Did you try
>wiping the spool dir out first?
No, it is a live server. :)
> Is the mail inbound or outbound?
Inbound
> or does it matter?
I didn't try the other case, submitting mail locally rather than via SMTP.
> This frag is from exim or you manaully sending somethin into exim?
I don't understand the question, I'm afraid.
> I would guess that a mailbox has bad perms,
I find that unlikely since it's writing the spool file when this error is
encountered. It's not been 'transported' yet, it's just being accepted.
> or a spool dir has bad perms
/usr/exim/spool/msglog/*/ and /usr/exim/spool/input/*/ are owned by the correct
user and group with the correct permissions. (We use split_spool_directory)
> . If you've already looked at that, I'd find where the messages is
> being written in the code, and see what it is doing. Another guess is
> you compiled with a different spool directory, and it doesn't even exist.
Both binaries were compiled with the same Local/Makefile, and were using
the same configuration file, so the spool directory will be consistent.
In any case - the new binary did not suffer the problem during testing, and
hasn't suffered from the past few days in active service, so I think whatever
was causing the problem was fixed in newer versions of Exim. (Perhaps the
ChangeLog entry I mentioned, for example).
Thanks for taking the time to give your thoughts.
Yours,
Ollie
--
Oliver Cook Systems Administrator, ClaraNET
ollie@??? 020 7903 3065
