[milters] Archive

Lists Index Date Thread Search

Article: 1134
From: Anthony Howe
Date: 2006-09-06 05:22:33 -0400
Subject: Re: Problem reloading access.db

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

Rob McMahon wrote:
> 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

Hmm. Stop the milter, discard the milter-ahead cache, start the milter, 
updates the access database and tell me if the changes are correctly 
picked up. It might be the case that the cache is holding a failure 
result and so ignoring changes in access.db.

If this doesn't solve the problem, contact me off-list.

> 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.

The adding of access.db support to milter-ahead came in 1.1 based on a 
user request for their university and was altered once again to default 
disabled in 1.3 as it was causing support issues for existing users used 
to the original 0.x / 1.0 behaviour.

> 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.

It could be the flock() semantics you previously mentioned. As a quick 
test edit

	cd com/snert/src/lib
	sed -e '/HAVE_FLOCK/s/.*/#undef HAVE_FLOCK/' \
		../../include/com/snert/lib/version.h
	make clean build
	cd ../milter-ahead
	make clean build
	sudo make install

libsnert has an flock() emulation function that will try other methods 
of file locking, see lib/io/flock.c; first choice being fcntl() if 
HAVE_FCNTL is defined.

If this works, then I'll have alter the configuration file for Solaris 
to make a different choice over flock. My choice in using flock() was 
based on the issue of file locking as described by Mark Crispin for the 
uw-imap package.

http://www.washington.edu/imap/documentation/locking.txt.html

> 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 ?

I've recently added to the upcoming libsnert/1.63 TextNull() and 
TextEmpty() functions as NULL guards for use in printf-like functions in 
order to address Solaris's difference from glibc. TextNull() returns 
"(NULL)" if the string is a NULL pointer and TextEmpty() returns "" if

the string is a NULL pointer. I'm so used to the glibc behaviour if 
doing this check for me that I relied on it in most of the function 
trace code. I'm slowly correcting them as I find them.

-- 
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