From: Anthony Howe
Date: 2006-09-06 05:22:33 -0400
Subject: Re: Problem reloading access.db
More information..: http://www.milter.info/#Support
Rob McMahon wrote:
> Anthony Howe wrote:
>> 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: [ID 889226 mail.info]
> reopening "/etc/mail/access_db.db"
> Sep 5 16:25:51 mail-relay-3 milter-ahead: [ID 513518 mail.error]
> 02393 NOQUEUE: connection loadbalancer1 [18.104.22.168] 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
sed -e '/HAVE_FLOCK/s/.*/#undef HAVE_FLOCK/' \
make clean build
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
> 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
Copyright 2009, 2012 by SnertSoft. All rights reserved.