Столкнулся с тьмой сабжа в логах exim`а, после его установки. Как я понял, когда чего-то там заблокировано, мыло откладывается... и потом приходит ко мне аж 9! часов спустя.Нашел описание проблемы в эксимовском хандбуке:
By default, the appendfile transport uses non-blocking calls to fcntl() when locking an open mailbox file. If the call fails, the delivery process sleeps for lock_interval and tries again, up to lock_retries times. Non-blocking calls are used so that the file is not kept open during the wait for the lock; the reason for this is to make it as safe as possible for deliveries over NFS in the case when processes might be accessing an NFS mailbox without using a lock file. This should not be done, but misunderstandings and hence misconfigurations are not unknown.
On a busy system, however, the performance of a non-blocking lock approach is not as good as using a blocking lock with a timeout. In this case, the waiting is done inside the system call, and Exim's delivery process acquires the lock and can proceed as soon as the previous lock holder releases it.
If lock_fcntl_timeout is set to a non-zero time, blocking locks, with that timeout, are used. There may still be some retrying: the maximum number of retries is
(lock_retries * lock_interval) / lock_fcntl_timeout
rounded up to the next whole number. In other words, the total time during which appendfile is trying to get a lock is roughly the same, unless lock_fcntl_timeout is set very large.
в силу своих познаний в английском языке, понял, что мне нужно либо отключить эту штуку вообще(ибо т.к. я почту по NFS не гоняю - мне эта фишка совсем по боку), либо использовать "blocking lock".
Правда больше не фига не понятно(ибо английский хромает). Подскажите, что и где нужно прописать, что бы решить проблему?
В exim.conf не нашел никаких упоминаний насчет этих lock`ов.