ph10@??? writes: >On Fri, 8 Dec 2000, Armin M. Hornetz wrote:
>
>> "D=system_aliases defer (-18): failed to open /et#/aliases for linear
>> search: No such file or directory"
>>
>> Although exim seems to work fine for several weeks, it once in a while
>> turns wild and gets /et#/aliases instead of the default /etc/aliases
>
>I have not seen any report like this before. Which release of Exim?
> exim 3.0.2 under SuSE Linux (6.x)
We are using exim on 7 different PCs with up to 800.000 messages per day
per server.
As we experienced the same problem on at least two different machines, one
with high traffic and one with low traffic. I can not believe it to be a
memory or hard disk problem as the odds are highly against the same bit
error or hard disk error to happen on two different machines. And I can't
see how a memory error can result in a single bit error at the same
location on two different installations and not resulting in more trouble
with other process data.
The problem vanished after restarting exim, but came back the other day.
Another server had the same problem some year ago but not since then.
The first thought was, that too many exim instances at the same time might
confuse some shared memory or overload some string-allocations. But the
logs show that there was no traffic for some minute and then the first
mail after the pause could not be processed because of the corrupt path.
