[milters] Archive

Lists Index Date Thread Search

Article: 1128
From: Anthony Howe
Date: 2006-09-05 08:10:16 -0400
Subject: Re: Problem reloading access.db

Removal...........: milters-request@milter.info?subject=remove
More information..: http://www.milter.info/#Support
--------------------------------------------------------

Rob McMahon wrote:
> Removal...........: milters-request@milter.info?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
> 
> libsnert-1.60
> milter-ahead-1.3

There are updates.

> sendmail-8.13.8
>    on
> 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 
option.

> -H
> -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[29478]: [ID 889226 mail.info] 
> reopening "/etc/mail/access_db.db"
> Sep  5 09:55:20 mail-relay-1 milter-ahead[29478]: [ID 820735 
> mail.warning] 08725 NOQUEUE: host jester-snat-dflt [137.205.195.97] 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[27216]: [ID 930459 mail.info] 
> 00013 NOQUEUE: host jester-snat-dflt [137.205.195.97] 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 
mind.

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
> 
> NOTES
>     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 
> unsupported.
> 
> 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
     http://www.snertsoft.com/

Lists Index Date Thread Search