On Mon, 29 Jan 2001, Jim Pazarena wrote:
> Here is an entry I discovered in a main.log file on a system which only
> send ONE email a night:
>
> 2001-01-29 12:49:59 14NLFP-000PcK-00 <= root@??? U=root P=local
> S=340 T="test to root" from <root@???> for root
> 2001-01-29 12:49:59 14NLFP-000PcK-00 failed to open DB file /u/exim/spool/db/wait-remote_smtp: File exists
> ---
> upon examination of the file, it has:
> -rw-r------ 1 mail mail 0 Jan 17 00:05 wait-remote_smtp.lockfile
> ---
>
> Since this 'lockfile' hasn't been *touched* since jan 17th, why, day after
> day does exim not clobber it? I have the same lockfile error message every
> day since Jan 17th.
It's not a lockfile error message! It's trying to open the DBM file and
failing. Nothing to do with the lockfile. Quite what the error is, I
don't know. I suggest you delete all the files in /db at a quiet time,
and see if the problem recurs.
Exim does not clobber the lockfile because it does not need to clobber
it. When it wants to lock the DBM file, it opens the lock file, and
takes out a lock (using fcntl()) on it. When it has finished, it
releases the lock and closes the file. The mere existence of the file is
not relevant.
Indeed, if it tried to rm the lock file, it could cause a problem
because of the way Unix filing systems work. Consider:
. Exim process A creates a lock file and takes out a lock while it is
updating the database.
. Exim process B comes along, finds the lock, so waits for the lock on
the file to be released, keeping the file open (and therefore in
existence).
. Exim process A releases the lock - so process B gets it and starts
doing whatever.
. If Exim process A unlinks the file, then yet another process C will
see no file, so it will create a new, different one, and get the lock.
At this point, both B and C have access to the database simultaneously.
--
Philip Hazel University of Cambridge Computing Service,
ph10@??? Cambridge, England. Phone: +44 1223 334714.
