Milter-greylist

Hi,

    We were experiencing this with 2.0.2 and we just upgraded to 3.0.1
and we are still seeing it.

    I thought that milter-greylist was supposed to re-read its config
file automatically and ajust (and I can see the reload log entry). 
Should we come back to the old method of restarting milter-greylist
after editing greylist.conf?  We have a few servers that  are MXSYNCs
so what I usually do is edit the file on one server, then I run a
script that

- does a milter-greylist -c
- tests the return value
- if it is not equal to 0, it exits with an error message
- if it is zero it copies greylist.conf to the other servers
- it does a milter-greylist -c on each other servers and tests the
return value.

Is there something wrong with my procedure?

Regards,

Ugo

--- In milter-greylist@yahoogroups.com, "Ugo Bellavance" <iolubik@...>
wrote:
>
> Hi,
> 
>     We were experiencing this with 2.0.2 and we just upgraded to 3.0.1
> and we are still seeing it.
> 
>     I thought that milter-greylist was supposed to re-read its config
> file automatically and ajust (and I can see the reload log entry). 
> Should we come back to the old method of restarting milter-greylist
> after editing greylist.conf?  We have a few servers that  are MXSYNCs
> so what I usually do is edit the file on one server, then I run a
> script that
> 
> - does a milter-greylist -c
> - tests the return value
> - if it is not equal to 0, it exits with an error message
> - if it is zero it copies greylist.conf to the other servers
> - it does a milter-greylist -c on each other servers and tests the
> return value.
> 
> Is there something wrong with my procedure?

New info:

On some servers it comes back to the correct configuration after a few
seconds, but on other servers, it takes more than 2 minutes, which is
a lot.  We guess it depends on the load on the server.

I know we could re-compile with 1 min of delay to minimize the impact,
but if, for example, a host that is whitelisted in greyist.conf
happens to send an e-mail during this window where the config file is
ignored, it is not very good...

Any ideas?

If you need more info, I'll do what I can to provide it.

Regards,

Ugo

On Tue, Feb 20, 2007 at 04:13:08PM -0000, Ugo Bellavance wrote:
> On some servers it comes back to the correct configuration after a few
> seconds, but on other servers, it takes more than 2 minutes, which is
> a lot.  We guess it depends on the load on the server.
(snip)
> Any ideas?

I see two potential issues:

1) too many threads within milter-greylist, and it's impossible to grab
the lock and reload the config file before 2 minutes

2) too many processes on the system, and milter-greylist waits 2 minutes
for being schedules

I'll assume you are in the first situation. How to handle it properly? 
If you kill the sendmail instances that are talking to a client, what happens?

-- 
Emmanuel Dreyfus
manu@...

--- In milter-greylist@yahoogroups.com, Emmanuel Dreyfus <manu@...> wrote:
>
> On Tue, Feb 20, 2007 at 04:13:08PM -0000, Ugo Bellavance wrote:
> > On some servers it comes back to the correct configuration after a few
> > seconds, but on other servers, it takes more than 2 minutes, which is
> > a lot.  We guess it depends on the load on the server.
> (snip)
> > Any ideas?
> 
> I see two potential issues:
> 
> 1) too many threads within milter-greylist, and it's impossible to grab
> the lock and reload the config file before 2 minutes
> 
> 2) too many processes on the system, and milter-greylist waits 2 minutes
> for being schedules
> 
> I'll assume you are in the first situation. How to handle it properly? 
> If you kill the sendmail instances that are talking to a client,
what happens?

What do you mean exactly, do a killall sendmail or a killall -HUP
sendmail after editing the greylist.conf file?