restarting spamd makes spam slip through?

Tue, 2006-08-08 at 18:21 +0200, Andreas Pettersson wrote:
Hi all.

I run Exim 4.63 and SpamAssassin (from acl) on FreeBSD.
Sometimes when I need to restart spamd I find that a few spam mails slip
through, even though spamd is unavailable for less than a second. To
prevent this from happening I tried to stop exim first, wait a few
seconds, and then restart spamd, but the problem still occurs sometimes.

I get three of these in paniclog:
spam acl condition: warning - spamd connection to 127.0.0.1, port 783
failed: Connection refused
spam acl condition: all spamd servers failed

How can I make sure exim has nothing 'going on' while I restart spamd?

Hello,

We have the same problem. mailhubs use Fedora Core 4, and running
'service exim stop' doesn't shutdown all the exim processes immediately.
In fact it can take several minutes, and usually running the command a
second time finally removes all the exim processes. Then we restart
spamassassin.

If you are using SA rules-de-jour, you will still have the problem when
SA is restarted after updates. As far as I remember SA is restarted, but
the MTA is not stopped/restarted, hence you'll still get those messages
in the panic log.

The suggestion of a check in the ACL is interesting. May well
investigate that one :-) I guess a check before calling SA is needed to
avoid the panic log entries.

John.

Wed, 2006-08-09 at 15:17 +0200, "Cdric MARCUX (sprimont)" wrote:
use the defer_ok clause to set exim to don't care about health of
spamassassin and clamd
We already use 'defer_ok'. It doesn't seem to help in this case.
John.

John Horne schrieb:
Wed, 2006-08-09 at 15:17 +0200, "Cdric MARCUX (sprimont)" wrote:
>use the defer_ok clause to set exim to don't care about health of
>spamassassin and clamd
>>
We already use 'defer_ok'. It doesn't seem to help in this case.

That is exactly your problem. 'defer_ok' tells exim that it is ok, if
spamd doesn't react in time, e.g. because it is down.

If you don't want exim to deliver mail if spamd is down, get rid of the
'defer_ok' qualifier. Exim then tells the offering mta to resend the
message at a later point in time.

The same holds true for virus scanner usage, of course. You don't want
any 'defer_ok' qualifier there neither.

HTH,
Patrick Eisenacher

John Horne wrote:
Wed, 2006-08-09 at 15:17 +0200, "Cdric MARCUX (sprimont)" wrote:
>use the defer_ok clause to set exim to don't care about health of
>spamassassin and clamd
>>
We already use 'defer_ok'. It doesn't seem to help in this case.

defer_ok is the _cause_ of your problem. It tells exim that if
spamassassin is temporarily broken (which would normally defer the
message), it's ok to just ignore the spamassassin rule and just continue
to the next rule. If you remove defer_ok, then when spamassassin is
down, all mail will be deferred until spamassassin is back up and can
process the mail.
- Marc

Wed, 2006-08-09 at 18:20 +0200, exim-users (AT) securitects (DOT) com wrote:
John Horne schrieb:
Wed, 2006-08-09 at 15:17 +0200, "Cdric MARCUX (sprimont)" wrote:
>use the defer_ok clause to set exim to don't care about health of
>spamassassin and clamd
>>
We already use 'defer_ok'. It doesn't seem to help in this case.

That is exactly your problem. 'defer_ok' tells exim that it is ok, if
spamd doesn't react in time, e.g. because it is down.

! Yes, that makes sense :-) I'll remove it and see what happens.

Thanks,

John.

Tue, 08 Aug 2006 18:21:15 +0200, Andreas Pettersson
<andpet (AT) telia (DOT) comwrote:
>I run Exim 4.63 and SpamAssassin (from acl) on FreeBSD.
>Sometimes when I need to restart spamd I find that a few spam mails slip
>through, even though spamd is unavailable for less than a second. To
>prevent this from happening I tried to stop exim first, wait a few
>seconds, and then restart spamd, but the problem still occurs sometimes.
>
>I get three of these in paniclog:
>spam acl condition: warning - spamd connection to 127.0.0.1, port 783
>failed: Connection refused
>spam acl condition: all spamd servers failed

Same thing happens when clamav is reloading its virus databases after
an upgrade. No big deal, but annoying, since the panic log gets these
messages and log checking mechanisms are going to fire.

I'd like exim to behave a little more tolerant here.

Greetings
Marc

Quoting Marc Haber:

Same thing happens when clamav is reloading its virus databases after
an upgrade. No big deal, but annoying, since the panic log gets these
messages and log checking mechanisms are going to fire.

I'd like exim to behave a little more tolerant here.

It probably should, but clamav could also be more nice here. A clamav
client cannot know that clamd will be back in a sec. Exim could retry
after some seconds (how many seconds and how often?). That will delay
all mail when clamd is really down, but that shouldn't be a problem for
smtp.

Wed, 09 Aug 2006 22:22:52 +0200, Jakob Hirsch <jh (AT) plonk (DOT) dewrote:
>Quoting Marc Haber:
>Same thing happens when clamav is reloading its virus databases after
>an upgrade. No big deal, but annoying, since the panic log gets these
>messages and log checking mechanisms are going to fire.
>
>I'd like exim to behave a little more tolerant here.
>
>It probably should, but clamav could also be more nice here.

Agreed. But the clamav upstream is much less cooperative than exim's
upstream ;)

Greetings
Marc