From: Anthony Howe
Date: 2006-09-05 08:10:16 -0400
Subject: Re: Problem reloading access.db
More information..: http://www.milter.info/#Support
Rob McMahon wrote:
> Removal...........: email@example.com?subject=remove
> More information..: http://www.milter.info/#Support
> I've recently put milter-ahead into production, and I'm having issues
> when the access.db is updated. This is
There are updates.
> SunOS harebell 5.9 Generic_118559-11 i86pc i386
> milter-ahead.cf looks like
> -f /etc/mail/sendmail-rx.cf
If you don't need access.db support (historical behaviour), remove this
> -N /etc/mail/nexthopdb.db
> -c 86400
> -C 86400
> -v info
These change with the updates to a new format.
> When the access.db is updated by makemap, I start getting errors like this:
> Sep 5 09:55:20 mail-relay-1 milter-ahead: [ID 889226 mail.info]
> reopening "/etc/mail/access_db.db"
> Sep 5 09:55:20 mail-relay-1 milter-ahead: [ID 820735
> mail.warning] 08725 NOQUEUE: host jester-snat-dflt [188.8.131.52] from
> unknown TLD
> but 137.205/16 is explicitly white-listed:
> milter-ahead-connect:137.205 OK
> after a restart it returns to:
> Sep 5 09:55:42 mail-relay-1 milter-ahead: [ID 930459 mail.info]
> 00013 NOQUEUE: host jester-snat-dflt [184.108.40.206] OK
> Sounds like a locking issue ? Any ideas ?
All my milters use fstat() on the open access.db file to detect when the
file is updated so that it can be reopened. fstat() is more efficient
than stat() when you have an open file descriptor.
Some access.db update scripts or makefiles do the following:
makemap hash access.new <access
mv access.new.db access.db
fstat() will NOT detect updates when using such an idiom. Even though
the access.db is replaced, the milter still contains an open file
descriptor to the old access.db; something about a file not being
deleted until all open file descriptors on that file are closed comes to
Simply overwriting access.db instead of "build & replace" works, like:
makemap hash access <access
When the access.db is overwritten, fstat() sees the update and reopens
the file correctly.
> My current thinking is to move to milter-ahead-1.5, turn on
> smdb-use-stat, and point milter-ahead at a copy of the access.db which
smdb-use-stat is experimental; it may or may not work as desired. It was
added to deal with "build & replace" problem. I added it based on a
request from someone, but have never really tested it to any degree. At
the time it was added (last year), the user reported that it failed
horribly. Since fstat() is the preferred, tested, and supported method I
never pursued it further.
> is atomically replaced. I'd like to understand the issue, though. I do
> note that libsnert uses flock, rather than fcntl, and that the man page
> for flock says
> Use of these interfaces should be restricted to only applications
> written on BSD platforms. Use of these interfaces
> with any of the system libraries or in multi-thread applications is
> So I wonder if it's tripping over this.
No. Not unless its over NFS. But the flock() won't come into play unless
fstat() detects a file update.
Anthony C Howe Skype: SirWumpus SnertSoft
+33 6 11 89 73 78 AIM: SirWumpus Sendmail Milter Solutions
http://www.snert.com/ ICQ: 7116561
Copyright 2009, 2012 by SnertSoft. All rights reserved.