[Avcheck] an idea: removing defer_transports?

[Michael Tokarev]

I just thought about an ability to do safe restarts
of avdaemon et al.  How about creating a file somewhere
during daemon restarts, so that avcheck will temporary
stop attempting to contact daemon?  Daemon restart
will be as follows:

 touch /var/spool/avp/noconn
 sleep 10 # to allow any pending checks to complete
 restart avdaemon
 rm /var/spool/avp/noconn

When /var/spool/avp/noconn is present, avcheck will
not contact antivirus daemon but will return TEMPFAIL
immediately (without even creating a message file),
and MTA will retry as usual (thus operate just like
if defer_transports=avcheck was set during that period).

This way, no munging with MTA's config files will be
needed at all.

Why all this you might ask?  Why not just restart
daemon without any additional actions?  Avcheck will
not be able to connect to antivirus anyway during
restart, and it will exit with EX_TEMPFAIL in case
of any unexpected daemon behaviour (like short read
for example).  Well, this is true for a good antivirus.
Unfortunately, as my own expirience shows, avpdaemon
sometimes just not checks it's input and reports
"all are ok" if interrupted during some operation.
I performed some aggressive testing -- passing a
big file to it to check and killing/restarting
at the same time.  Sometimes, but in very rare
cases, daemon tells "file is clean" to it's
client.  Most of the time it just returns
"reloading in progress" result code that
avcheck will treat as temporary error, and
another great amount was "connection refused"
errors (also treated as temporary).  So, in
very rare situations, when your mailsystem
processes an infected message *and* you're
issued restart command for your avpdaemon,
that message can pass antivirus filter.

It seems that this bad situation occurs when
daemon interrupted at very beginning of
scanning process (right after fork to handle
request or something near this).  So it is
a question: may be just do nothing -- no
defer_transport, no this new functionality, --
nothing.  Situation is *very* rare, really...

Regards,
 Michael.