Milter-greylist

Hi,

Still running Milter-greylist 1.4 (with just a few lines
commented to avoid too much syslog logging) in -T mode.
Works great except I'm seeing thousands of lines such as :

Nov  9 15:11:46 mail milter-greylist: peer x.x.x.x queue overflow (-1 entries),
discarding new entry
Nov  9 15:12:00 mail milter-greylist: peer x.x.x.x queue overflow (-1 entries),
discarding new entry
Nov  9 15:12:06 mail milter-greylist: peer x.x.x.x queue overflow (-1 entries),
discarding new entry

Apparently it comes from sync.c :
    790         if (peer->p_qlen >= SYNC_MAXQLEN) {
    791                 syslog(LOG_ERR, "peer %s queue overflow (%d entries), "
    792                     "discarding new entry", peer->p_name, peer->p_qlen);

It seems that most of the time syncing despite of these error messages.
A kind of warning ?

I recall some posts about a new stable version ...
Could it be possible to have some release candidate versions ?


PS : I will try to propose an initscript for SUSE (or update the existing
one to support both SUSE/RH/Mandrake).


PS2 : at a time I had a problem with the milter-greylist.db file.
There was an odd address <Q[5-]@...> causing fatal parsing errors
on restart. Removing this line solved the pb.
Regards,

SL/

<milter@...> wrote:

> Nov  9 15:12:06 mail milter-greylist: peer x.x.x.x queue overflow (-1
> entries), discarding new entry
> 
> Apparently it comes from sync.c :
>     790         if (peer->p_qlen >= SYNC_MAXQLEN) {
>     791                 syslog(LOG_ERR, "peer %s queue overflow (%d
entries), "
>     792                     "discarding new entry", peer->p_name,
peer->p_qlen);
> 
> It seems that most of the time syncing despite of these error messages.
> A kind of warning ?

A bug.
 
> I recall some posts about a new stable version ...
> Could it be possible to have some release candidate versions ?

Well I can rename 1.5.11 to 1.6RC1 if that makes you happy, but it will
still be the same software.

In fact 1.5.11 will turn into 1.6 if we find no bugs in it.
  
> PS : I will try to propose an initscript for SUSE (or update the existing
> one to support both SUSE/RH/Mandrake).

Yes, it will be better to modify the existing rc-linux.sh so that it
accomodates more Linux flavors.
 
> 
> PS2 : at a time I had a problem with the milter-greylist.db file.
> There was an odd address <Q[5-]@...> causing fatal parsing errors
> on restart. Removing this line solved the pb.

I beleive this was fixed in recent releases.

-- 
Emmanuel Dreyfus
Il y a 10 sortes de personnes dans le monde: ceux qui comprennent 
le binaire et ceux qui ne le comprennent pas.
manu@...

Hello,

> > Nov  9 15:12:06 mail milter-greylist: peer x.x.x.x queue 
> overflow (-1
> > entries), discarding new entry
> > 
> > Apparently it comes from sync.c :
> >     790         if (peer->p_qlen >= SYNC_MAXQLEN) {
> >     791                 syslog(LOG_ERR, "peer %s queue overflow (%d
> entries), "
> >     792                     "discarding new entry", peer->p_name,
> peer->p_qlen);
> > 
> > It seems that most of the time syncing despite of these 
> error messages.
> > A kind of warning ?
> 
> A bug.
>  

Could you try with this patch and let us know if it solves your problem?

Bests,
Attila

<attila.bruncsak@...> wrote:

> Could you try with this patch and let us know if it solves your problem?

This seems like a bugfix that should be applied to the latest source
even if it does not fix a problem on his system. What do you think?

-- 
Emmanuel Dreyfus
Il y a 10 sortes de personnes dans le monde: ceux qui comprennent 
le binaire et ceux qui ne le comprennent pas.
manu@...

Hello,

> > Could you try with this patch and let us know if it solves 
> your problem?
> 
> This seems like a bugfix that should be applied to the latest source
> even if it does not fix a problem on his system. What do you think?
> 

Yes, it is for the latest source. Easy to modify for the 1.4 also,
but I recommend to use always the latest source.
I do not think that the 1.5.11 would be less stable than the 1.4

Bests,
Attila

Hello,

I have an other patch for the queue overflow handling.
I think it is better than the previous one.
The previous one had a bug in the sync_sender function.
The condition of the while loop should have been locked
together with the removal of the sync entry.
In this new patch the sync queue handling is concentrated
only into two new functions: sync_queue_poke and sync_queue_peek.
It is rather self explainable what they are doing.
Disadvantages:
 - When new sync entry is created malloc and free
   is going to be done even the queue is already full.
 - On config reload there may be many lock - unlock
   executed on each sync_queue.
   For this one I plan to have an other patch:
   On config reload if the new peer was already existing
   there is no need to change anything on the peer structure,
   including its sync queue. 
It has to be applied to the plain 1.5.11 distribution.

Bests,
Attila

PS: for the sync.h I made conditional definition of SYNC_MAXQLEN,
I could test my patch with CFLAGS="-DSYNC_MAXQLEN=4" on configure stage.
It should not heart. Somebody else may use it as well wanting
different value than 1024 for SYNC_MAXQLEN.

<attila.bruncsak@...> wrote:

> I have an other patch for the queue overflow handling.
> I think it is better than the previous one.

Committed. That's a rather complex change, I hope you tested it well.
We'll probably have to do a 1.5.12 before going 1.6, to make sure no bug
was introduced.

-- 
Emmanuel Dreyfus
Il y a 10 sortes de personnes dans le monde: ceux qui comprennent 
le binaire et ceux qui ne le comprennent pas.
manu@...

Hello,

> 
> > I have an other patch for the queue overflow handling.
> > I think it is better than the previous one.
> 
> Committed. That's a rather complex change, I hope you tested it well.
> We'll probably have to do a 1.5.12 before going 1.6, to make 
> sure no bug
> was introduced.
> 

Already using it on my side in production with 6 mailservers
synchronizing with each other.
I continously keep my eyes on them, no problem for the time being.
I support to have a 1.5.12 before comitting to 1.6.

Bests,
Attila