[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.
--------------040008000004080606070609
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 [137.205.195.67] blocked
Sep  5 16:25:51 mail-relay-3 milter-ahead[5242]: [ID 820735 
mail.warning] 02393 NOQUEUE: host loadbalancer1 [137.205.195.67] from 
unknown TLD
Sep  5 16:25:51 mail-relay-3 milter-ahead[5242]: [ID 513518 mail.error] 
02393 NOQUEUE: connection loadbalancer1 [137.205.195.67] 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 [137.205.195.67] 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 
work.
> 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 ?

Cheers,

Rob

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


--------------040008000004080606070609
Content-Type: text/plain;
 name="xx"
Content-Transfer-Encoding: base64
Content-Disposition: inline;
 filename="xx"

PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PQpSQ1MgZmlsZTogRG5zLmMsdgpyZXRyaWV2aW5nIHJldmlzaW9uIDEu
MQpkaWZmIC11IC1yMS4xIERucy5jCi0tLSBEbnMuYwkyMDA2LzA5LzA1IDEzOjI5OjUwCTEu
MQorKysgRG5zLmMJMjAwNi8wOS8wNSAxMzozMTowMQpAQCAtMTY3OCw3ICsxNjc4LDggQEAK
IAlyYyA9IDA7CiBlcnJvcjA6CiAJaWYgKDAgPCBkZWJ1ZykKLQkJc3lzbG9nKExPR19ERUJV
RywgIkRuc0luaXQoJXMpIHJjPSVkIiwgcmVzb2x2X2NvbmYsIHJjKTsKKwkJc3lzbG9nKExP
R19ERUJVRywgIkRuc0luaXQoJXMpIHJjPSVkIiwKKwkJICAgICAgIHJlc29sdl9jb25mID8g
cmVzb2x2X2NvbmYgOiAiTlVMTCIsIHJjKTsKIAogCXJldHVybiByYzsKIH0K
--------------040008000004080606070609--

Lists Index Date Thread Search