On Fri, 7 Jun 2002, Dave C. wrote:
> Just a note - exims ability to deliver mail does not hinge on it being
> able to lock, or even access, its hints db. It doesnt prevent mail from
> being delivered, if it cant update a hint, it just goes on without them
> without any ill effect.
In theory, yes, and I dealt with the problem temorarily by just deleting
the retry* files every 3 minutes. This hurts delivery efficiency however,
as down hosts continually get retried, etc.
Where this really kicked me in the balls, though, was the timeout on
trying to lock the retry db. For each message (and possibly each
recipient of each message, a try for a lock on the retry file occurred,
with a timeout of about 1 minute. This timeout was an absolute killer and
resulted in huge queues building. I managed to get the queue under
control by continually deleting the retry* files, but this is not a long
term solution.
--John
> On Fri, 7 Jun 2002, John Jetmore wrote:
>
> >
> > (exim 3.36)
> >
> > Since starting to use exim I have occasionally experienced times where one
> > or another server will be unable to lock one of the hints databases
> > (usually retry). While it is inconvenient, it is not the end of the
> > world. I delete the db and the lockfile and the world moves on. Earlier
> > this week, however, several events occurred simultaneously and have made
> > this much more of an issue. The problems were two separate but equally
> > voracious spammers, the failure of our primary mail server, the above
> > mentioned locking problem occurring on our primary mailbagger, and yours
> > truly being out of town and uncontactable. The end result was a huge
> > number of _legitimate_ mail in queue on the mail bagger after the spam
> > had been identified and deleted.
> >
> > So, this got me to wondering about the nature of locking for these hints
> > dbs. Almost everything in the docs refers to locking for appendfile
> > transport and so forth. Pretty much the only mention of locking and the
> > hints dbs is that it does occur. Looking at the source, it appears that
> > only fcntl locking is done. The file it locks is called .lockfile, but
> > the file doesn't seem to use true lockfile locking (hitching post creation
> > and whatnot).
> >
> > This seems like an issue to me as our db directory is on NFS (a netapp
> > F760). In fact, the whole spool directory is on NFS, and has for the most
> > part worked beautifully. We have experienced in the past w/ flock times
> > where files on NFS will become unlockable - that is, not only does locking
> > not work, but it sort of permanently "freezes out" all locks on that
> > inode. fcntl in this case certainly appears to be doing the same thing,
> > which explains why removing the files (and thus generating new inodes)
> > works here. I had thought that problems like this were why exim
> > supported lockfiles so much, but I see in the book that it actually had
> > something to do with the size of the file reported by the NFS server. I
> > suppose if this is the reason lockfile wouldn't be viewed as necessary
> > because the file that gets locked contains no data itself.
> >
> > Does anyone experience problems like this? Is there any chance of getting
> > lockfiles for hints dbs? I convinced my boss that exim was NFS/lockfile
> > clean when we moved to it, I would certainly hate to have to use local
> > storage now. Also, are there any other places where fcntl is used only?
> >
> > Thanks
> > --John Jetmore
> >
> >
> >
> > --
> >
> > ## List details at http://www.exim.org/mailman/listinfo/exim-users Exim details at http://www.exim.org/ ##
> >
> >
>
>
> --
>
>
>
