Mailing List Archive

Patch for asynchronous clamd reload
Hi,
The attached patch is an implementation of the async reload feature that
was mentioned on clamav-users some time ago by Vivien Raoul. It
addresses the issue that reloading clamd makes it unavailable
temporarily by blocking the message reception loop; this is not
problematic for standard computers but it is for small systems where
reloads can take a bit of time.

The patch introduces a new clamd.conf option called AsyncReload. When
enabled, clamd treats reload requests by initializing a new engine, and
doing the load+recompile phases in a separate thread. The receive loop
watches for the completion of the operation at a reasonable interval,
set to 10s, and exchanges the current engine with the new one. Also the
reload_db function has been split in two, reload_db2 corresponding to
the asynchronous part of the process.

--
*Denis MARTINEZ*
Mobile research dept.

*PRADEO SECURITY SYSTEMS
* Rond Point Benjamin Franklin - 34960 MONTPELLIER cedex 2 - France
Mobile :+33(0)6 78 78 60 09 - Tel: +33(0)4 67 13 01 05 - Fax: +33(0)4 67
13 00 10

www.pradeo.net <http://www.pradeo.net>
Re: Patch for asynchronous clamd reload [ In reply to ]
On 03/28/2011 06:26 PM, Denis Martinez wrote:
> Hi,
> The attached patch is an implementation of the async reload feature that
> was mentioned on clamav-users some time ago by Vivien Raoul. It
> addresses the issue that reloading clamd makes it unavailable
> temporarily by blocking the message reception loop; this is not
> problematic for standard computers but it is for small systems where
> reloads can take a bit of time.
>
> The patch introduces a new clamd.conf option called AsyncReload. When
> enabled, clamd treats reload requests by initializing a new engine, and
> doing the load+recompile phases in a separate thread. The receive loop
> watches for the completion of the operation at a reasonable interval,
> set to 10s, and exchanges the current engine with the new one. Also the
> reload_db function has been split in two, reload_db2 corresponding to
> the asynchronous part of the process.

I wonder if engine replacement could be more cleanly done from the
reload thread, like I am doing here:

http://www.average.org/svn/zmscanner/zms_clamav/trunk/clamav_refreshdb.c

Of course it requires the scanning thread(s) to cooperate: in my case
they do so by calling pre_scan() and post_scan() before and after
processing a sample.

Plus, I think that your code may have a race condition because at least
in one place you are checking the value of async_reload_finished while
not holding reload_mutex. But I may be wrong here, I did not look
*really* close.

Regards,

Eugene