I've got an app which uses clamd's STREAM command to perform AV checking.
This app may, from time to time require multiple independent connections be
maintained concurrently to clamd. When my app is busily using clamd, I've
noticed what appears to be a deadlock condition between the app and clamd.
Looking closely at the logs in both my app and clamd's log (with LogClean
and LogVerbose enabled), I've determined that the deadlock happens when
clamd is trying to "partially wind down" activity in order to "reload" a new
AV database. The approach clamd implements to reload it's database is to
stop accepting new clamd client connections until all prior connections have
completed , after which the AV database is reloaded and connections are once
again processed. This approach allows a single "slow" client to essentially
block all other clamd activities.
I could change my app to more gracefully handle the constricting behavior of
clamd, or I could change clamd to implement AV db replacement in a more
graceful fashion. The second approach will benefit all clamd client
applications.
The attached patch to clamav-0.83 solves this problem by adding a reference
count to the cl_node structure. This allows independent instances of the
cl_node root structure to exist concurrently in clamd and for clamd to no
longer have to "throttle down connections" to install updated AV Database
information.
- Mark Pizzolato
clamav-0.83.patch.newreload
Description: Binary data
_______________________________________________
http://lists.clamav.net/cgi-bin/mailman/listinfo/clamav-devel
