[milters] Archive

Lists Index Date Thread Search

Article: 1129
From: Rob McMahon
Date: 2006-09-05 11:54:37 -0400
Subject: Re: Problem reloading access.db

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

This is a multi-part message in MIME format.
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Anthony Howe wrote:
>> libsnert-1.60
>> milter-ahead-1.3
> There are updates.
Yup, I was kind of waiting for the 1.6 version, which is mentioned, to 
appear on the download pages.  Anyway, I've installed milter-ahead-1.5 / 
libsnert-1.62, and converted the .cf file.  Doing

makemap hash access_db < access_db

caused it to immediately start complaining:

Sep  5 16:25:51 mail-relay-3 milter-ahead[5242]: [ID 889226 mail.info] 
reopening "/etc/mail/access_db.db"
Sep  5 16:25:51 mail-relay-3 milter-ahead[5242]: [ID 513518 mail.error] 
02393 NOQUEUE: connection loadbalancer1 [] blocked
Sep  5 16:25:51 mail-relay-3 milter-ahead[5242]: [ID 820735 
mail.warning] 02393 NOQUEUE: host loadbalancer1 [] from 
unknown TLD
Sep  5 16:25:51 mail-relay-3 milter-ahead[5242]: [ID 513518 mail.error] 
02393 NOQUEUE: connection loadbalancer1 [] blocked
Sep  5 16:25:51 mail-relay-3 sm-mta-rx[20479]: [ID 801593 mail.info] 
k85FPpID020479: milter=milter-ahead, action=connect, reject=550 5.7.1 
connection loadbalancer1 [] blocked

Doing a restart got back to the desired behaviour.  (Note these are just 
probes from our loadbalancers checking the health of the servers.)
>> -f /etc/mail/sendmail-rx.cf
> If you don't need access.db support (historical behaviour), remove 
> this option.
Hmm, I didn't realize this was considered historical.
> 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.
That makes sense to me, and it's also what sendmail uses, so it ought to 
> 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. 
No, I don't do that, I use the straight `makemap hash access_db < 
access_db' method.  I still don't understand what's going on.  It 
doesn't always fail.  On a quiet machine it's just fine.  On busy 
machines it fails maybe one time in two or three.  I'll carry on digging.
>> 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 
> 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.
Ah, okay.  We'll skip that one, then.  Thanks for the warning.  The 
problem is not completely debilitating, it just means I have to stop and 
start the milter around access_db updates, which really don't happen 
that often.

While I'm here, can I ask for the attached patch to be included to save 
a new occurrence of the old NULL pointer dereference problem on 
Solaris.  I know you don't like Solaris's behaviour in this regard, but 
I have to say it's saved me on occasion.  Maybe a COULD_BE_NULL(s) macro 
for use in debug statements could be handy ?



E-Mail:	Rob.McMahon@warwick.ac.uk		PHONE:  +44 24 7652 3037
Rob McMahon, IT Services, Warwick University, Coventry, CV4 7AL, England

Content-Type: text/plain;
Content-Transfer-Encoding: base64
Content-Disposition: inline;


Lists Index Date Thread Search