On Sat, 20 Sep 1997, Dr. Rich Artym wrote:
> First of all, still within Exim's control, mailboxes are locked during
> local delivery and dbm files are locked during lookup, fine. Is there
> anything else that Exim locks? [Lsearch'd files are an obvious candidate
> since they may change concurrently with Exim's lookups, just like dbms.]
More specifically:
1. Mailboxes are locked during local delivery.
2. Exim's "hints" databases are locked during reading and writing.
3. Spool files are locked while being processed. (Well, just one of the
two files, actually.)
Other files are not. Lsearch'd files are not, nor are any dbm or other
configuration lookups (e.g. alias files). These are all read-only in
Exim.
This is an area where maybe work needs to be done. I didn't know as much
about dbm files and Unix when I was working in that area, but I did know
enough to write dbmbuild as a program that makes a new dbm database,
then renames it into place. This I believe is fine when using a DBM
library that uses just a single file, e.g. Berkeley DB. It is a problem
when using ndbm, which stores its data in two separate files, because
you can't replace two files atomically.
> Secondly, one can assume that Exim's locking is safe on a single machine
> under access by multiple instances of Exim itself, as well as with NFS-
> mounted filestores used by multiple instances of Exim executing on one
> machine, and also when Exim instances execute on separate machines. True?
For mailboxes, yes, I hope so. A lot of effort went into trying to get
that right. Note that the case of two Exims on separate machines
operating on the same remote NFS filestore works only if you configure
both Exims to use lock files, not just fcntl(), for locking mailboxes.
Essentially, Exim needs to get a lock *before* opening the remote file.
Otherwise the NFS caching breaks things.
> What about log files, spool files, and so on? Which items can safely
> be shared between multiple parallel (not just concurrent) instances of
> Exim executing on different hosts but sharing NFS space? (Presumably
> not *every* filestore object is locked by Exim before use, but that's
> OK as long as we know exactly which objects are and which aren't.)
Log files are not locked. Exim always writes log entries as a single
write() to a file opened with O_APPEND. This won't work for an NFS file
opened by two different hosts.
Spool files are locked using fcntl() while Exim is working on a message.
I hadn't ever thought of two different machines sharing the same spool.
Since the names of the spool files are generated using the pid of the
process that receives the message as well as the current time, they are
not globally unique and there will be a problem.
Essentially, the assumption is that each host has its own spool and log
files.
> Now comes the difficult bit, as we bring in other software.
You think the rest was easy? :-)
> Access to mailboxes is carried out under lock control by local user
> mail agents and system POP3 daemons. How safe are we in the presence
> of alternative locking systems or libraries? Is there an issue here
> at all? Do we have to read the small print on mail readers and POP3
> daemons to be certain that all is OK and compatible with Exim, or is
> it just that I enjoy worrying about concurrency? :-)
You have to read the small print and there is certainly an issue. Exim
by default uses both fcntl() and lockfile locking, on the belt-and-braces
principle.
> Finally, when we interface our local facilities to linear or dbm files
> used to control Exim, is there a preferred (read as "safest") method of
> updating such files?
Good question.
--
Philip Hazel University Computing Service,
ph10@??? New Museums Site, Cambridge CB2 3QG,
P.Hazel@??? England. Phone: +44 1223 334714
--
* 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/
