On Thu, 12 Jun 1997, Nigel Metheringham wrote:
> This isn't normal...
>
> } I'm running exim-1.624 on Slackware Linux 3.1 with GDBM 1.7.3.
> } I don't know if it is a feature of GDBM, but the retry.dir is a
> } hard link to retry.pag.
>
> Yes thats normal.
A feature of gdbm.
> Initially delete the hints databases and see if the problem recurs
It will. :-(
> } Should I switch to Berkeley DB 1.8.6 or 2.0.6?
Exim doesn't at present support gdbm properly. I am at this very moment
working on the support for the various db packages. The problem is that
gdbm does its own locking and there are various ways it can get confused
with Exim's attempts to lock. The results of my current investigation
are going to appear in a rather long README.DBM file...
If you switch to DB 1.85 (or 1.86; I don't think it matters), make sure
you install the ndbm.h file that comes with it in the correct place so
that Exim sees it. Alternatively, set USE_DB in your Local/Makefile to
use the Berkeley native interface. Otherwise you may get file corruption
problems.
The next release will have code that supports gdbm better, offering an
option to cut out Exim's own locking, and handling retries when gdbm
open fails because of its own locking. [*] There will also be a
prescription for testing the database routines so you can be confident
that *somebody* is doing the locking.
> Don't use Berkeley 2.x unless you are going to develop for it - the
> interface is not the same (and the performance if used in the way that
> exim does by default will be lousy). I'd suggest using DB 1.85 if you
> change at all. DB 1.86 fixes a problem that we should never see, and
> since the complete hash algorithm was changed I would say its better to
> stick with 1.85.
I'm investigating Berkeley 2.0 to see what the performance is really
like. So far I have reached "Segmentation Fault" :-(. I intend to put in
support for it though, as I imagine it will appear on various systems,
and even if the performance in Exim is poor, it won't matter on systems
that are lightly loaded.
Philip
[*] There is an interesting point about waiting for locks. Current Exim
always sleeps and tries again. The next release does a timed blocking
lock; this potentially acquires the lock sooner when the holder releases
it. For gdbm this cannot be done because it returns EAGAIN from the open
call when the file is locked, so the sleep/retry loop is the only thing
Exim can do.
--
Philip Hazel University Computing Service,
ph10@??? New Museums Site, Cambridge CB2 3QG,
P.Hazel@??? England. Phone: +44 1223 334714
