Milter-greylist

Hello,

The milter-greylist version 3.0a6 does not always reread
the configuration file if there is a new one available.

The version 2.1.4 always reads it.

Is this a planned change in behaviour, or a bug has been
introduced somewhere?

Bests,
Attila

On Tue, Sep 19, 2006 at 11:03:40AM +0200, attila.bruncsak@... wrote:
> The milter-greylist version 3.0a6 does not always reread
> the configuration file if there is a new one available.
> 
> The version 2.1.4 always reads it.
> 
> Is this a planned change in behaviour, or a bug has been
> introduced somewhere?

It's a bug. I also noticed it. 

-- 
Emmanuel Dreyfus
manu@...

At Tue, 19 Sep 2006 11:03:40 +0200,
<attila.bruncsak@...> wrote:
> 
> Hello,
> 
> The milter-greylist version 3.0a6 does not always reread
> the configuration file if there is a new one available.
> 
> The version 2.1.4 always reads it.
> 
> Is this a planned change in behaviour, or a bug has been
> introduced somewhere?

It is a bug introduced at 3.0a6. The conf_cold is always 1.

On Tue, Sep 19, 2006 at 06:47:36PM +0900, AIDA Shinra wrote:
> It is a bug introduced at 3.0a6. The conf_cold is always 1.

That seems to be the fix:

Index: milter-greylist.c
===================================================================
RCS file: /cvsroot/milter-greylist/milter-greylist.c,v
retrieving revision 1.137.2.2
retrieving revision 1.137.2.3
diff -U4 -r1.137.2.2 -r1.137.2.3
--- milter-greylist.c   4 Sep 2006 22:07:21 -0000       1.137.2.2
+++ milter-greylist.c   19 Sep 2006 13:31:26 -0000      1.137.2.3
@@ -887,8 +887,10 @@
 	}
 
 	openlog("milter-greylist", 0, LOG_MAIL);
 
+	conf_cold = 0;
+
 	if (conf.c_socket == NULL) {
 		 mg_log(LOG_ERR, "%s: No socket provided, exiting", argv[0]);
 		 usage(argv[0]);
 	}

-- 
Emmanuel Dreyfus
manu@...

Here is 3.0rc1:

http://ftp.espci.fr/pub/milter-greylist/milter-greylist-3.0rc1.tgz
MD5 (milter-greylist-3.0rc1.tgz) = b9bd8dc226ef54dc1ced49eeb6bd91b2

ChangeLog since 3.0alpha6:
3.0rc1
        Warn about ignored ACL lines after acl default rule
	Small documentation fix (Leena Heino)
	Fix automatic config reload


-- 
Emmanuel Dreyfus
manu@...

> > It is a bug introduced at 3.0a6. The conf_cold is always 1.
> 
> That seems to be the fix:
>

Yes, it fixes.
But now the previous MX sync problem on Tru64 UNIX shows up again. Is it possible to apply the previous fflush() patch again? Did this patch brake something on other platform?

Here is the extract from the man page of fopen(3) on Tru64 UNIX:

> When you open a file for update, you can perform both input and output
> operations on the resulting stream. However, an output operation cannot be
> directly followed by an input operation without an intervening call to the
> fflush() function or a file-positioning operation (fseek(), fsetpos(), or
> rewind() function). Also, an input operation cannot be directly followed by
> an output operation without an intervening flush or file positioning opera-
> tion, unless the input operation encounters the end of the file.

So between fprintf and fgets an fflush is required in select_protocol(). (extract of the original code):

                fprintf(stream, "vers%d\n", vers);

                sync_waitdata(s);
                if (fgets(line, LINELEN, stream) == NULL) {

There is on spurious fflush() a bit later that is not really needed.

Bests,
Attila

> Here is 3.0rc1:
> 
> http://ftp.espci.fr/pub/milter-greylist/milter-greylist-3.0rc1.tgz
> MD5 (milter-greylist-3.0rc1.tgz) = b9bd8dc226ef54dc1ced49eeb6bd91b2
> 
> ChangeLog since 3.0alpha6:
> 3.0rc1
>         Warn about ignored ACL lines after acl default rule
> 	Small documentation fix (Leena Heino)
> 	Fix automatic config reload
> 

Should not we call it beta instead of release candidate?
In the series two we had beta, for example: 2.0b5.

About the systems with missing vsyslog() again.

The reference to the LINE_MAX comes from the man page of syslog(3) on Tru64 UNIX,
here is an extract:

> format [value...]
>            Similar to the printf fmt string, with the difference that %m is
>            replaced by the current error message obtained from errno.  A
>            trailing newline can be added to the message if needed. The value
>            parameters are the same as the value parameters of the printf()
>            function.  Callers of syslog() must ensure that the message is
>            not longer than LINE_MAX bytes. Results are unspecified if sys-
>            log() is called with a message larger than LINE_MAX bytes.

I do not know does the utilization of LINE_MAX as constant macro creates any
problem on other platform with missing vsyslog()? Is this constant used for
something else or have a weird value there?

On the other hand the "%s" format string is imperative. It may be replaced with
"%s\n" if really needed I guess, but I did not tested it on Tru64 UNIX. 

I attach now a patch hoping that it does not create any problem.

Bests,
Attila

On Wed, Sep 20, 2006 at 12:06:15PM +0200, attila.bruncsak@... wrote:
> Should not we call it beta instead of release candidate?
> In the series two we had beta, for example: 2.0b5.

I had so few feedbacks on alpha6 that I decided to skip the beta stage.
I'm not sure it was a right move, but here we are.

> I do not know does the utilization of LINE_MAX as constant macro creates any
> problem on other platform with missing vsyslog()? Is this constant used for
> something else or have a weird value there?

No idea, we'll see with rc2...

-- 
Emmanuel Dreyfus
manu@...