[Avcheck] Warning: bad AVP behaviour

[Michael Tokarev]

I just noticied a problem with avp daemon, and thought
it will be useful to report it here.

Sometimes, avpdaemon refuses to return an answer after
it completes "inspection".  This happens very rare, and
I can't reproduce this situation.  When I restart it,
all works good.  But after some time, usually with a
large mail with attached archive, it stops working.

Simptoms are the following.  System's load is near 0,
all processes are in sleep.  There are two avcheck
processes awaiting for input from two avpdaemon processes.
All four does nothing (avpdaemon's also waits for
something from avchecks).  Since there is a limit on
how many parallel scans can be run, mail queue
grows (all queue jobs are active, i.e. marked by "*").
After some time, postfix's pipe will times out and
will bounce message back saying "command time limit
exceeded", killing avcheck process.

Interestingly, next scan will show the same bad
results sometimes, or may succed.  I noticied that
today was 3 big delays in mail delivery (usually
I receive about 10 messages per hour), and tons of
messages comed after those delays -- so avpdaemon
resumed it's work for some time, then stopped again
and so on.

All 3 delays was due to one same archive people
tried to send to me.  Funny enouth, it was new
beta version of DrWeb antivirus -- a competitor
for AVP (and this is really funny -- does avp
dislikes it's competitors *so* seriously???).
But I was unable to reproduce that myself --
I taked that message out of postfix queue when
it was "in process" of scanning, restarted avpd,
and then feeded that message into postfix's smtp.
No, it was processed quickly, without any glitch...

For now, I can't understand what's happened.
Definitely, something is wrong here, and I can't
say what.

I plan to implement a workaround for this -- using
timeout in avcheck and abortin a scan process after
it expires, with EX_TEMPFAIL (as usual!) exit code,
so that mail will not bounce.  I don't know if this
will help or not, since not shure if avpd will be
able to "eat" the message on next queue run (it may
do exactly the same bad things) -- and if not,
then it will look like a very good DoS (at least
not a serious one, *if* avp will not stop on
other "usual" messages).

BTW, Is it only me who encountered this problem?

Regards,
 Michael.