Piete Brooks writes:
>
> Any updates should be atomic (read "be done by file renaming").
> So, if you are using a dbm with a single file, you can (I think) quite safely
> copy the old file to a temp version, use your favourite dbm editing command to
> add the new info, and then atomically replace the file by a rename.
> Any long-running instances of exim may continue using the old file (if they
> have it open), so things may get inconsistant, but it should not be too much
> of a problem.
Note that this assumes the dbm file is on a UFS filing system, or something with
similar semantics: in particular not an NFS one. In the latter case, existing Exim
processes that had the old file open might get ESTALE errors trying to read it,
unless you (a) had only Exim processes running on one client system accessing
the file, (b) did your rename on that system, & (c) are prepared to trust the
cludgy .nfsXXXX mechanism.
As regards "long-running instances of Exim", by the way: the primary daemon process
(-bd and/or -q [time]) goes to some lengths to make sure it doesn't keep auxilliary
files open: it's only the configuration file itself changing that you need to HUP
it for. Every other Exim process ought to have a finite lifetime, even if it doesn't
seem like that sometimes...
Chris Thompson Cambridge University Computing Service,
Email: cet1@??? New Museums Site, Cambridge CB2 3QG,
Phone: +44 1223 334715 United Kingdom.
--
* This is sent by the exim-users mailing list. To unsubscribe send a
mail with subject "unsubscribe" to exim-users-request@???
* Exim information can be found at http://www.exim.org/
