Papp Tamás wrote:
Christoph Wilke wrote, On 2009. 12. 15. 16:32:
If it is as fast as libclamav and you have enough RAM, then clamd
has at least the advantage that you don't have to reload/restart clapf
if there are changes in your virus db.
Does it matters? Still need to reload something.
Indeed. The clamd daemon itself checks periodically if the virus
database has changed, and if so, it reloads.
BTW Janos, could it be possible, to detect the virus pattern changes
automatically?
In general, the virus database may change only if you actually run the
freshclam utility. I usually do this on my computer in every hour. So
it's not worth to check for changes too frequently. So yes, indeed the
clapf daemon may check itself for virus database changes, but I found it
simpler to implement to use a signal from 'outside'.
The util/update_clamav_sigs.sh script 'automatically' notifies clapf to
reload the database.
And another note about the clamd vs. libclamav issue. As you know the
clapf daemon is a forking one. If you use libclamav it means that every
child process (I would say ~10-20 at most installations) needs a certain
amount of memory to hold the signatures. I think the Linux copy-on-write
mechanism handles pretty well this burden, but be aware that things. The
clamd is a threaded daemon which lets all the threads share the same
address space, so the av signature must be in one instance in the
memory.
I suggest you to run a benchmark for clapf+libclamav and clapf+clamd.
Try with both always_scan_message=1 and always_scan_message=0 to see the
load, memory consumption, throughput, etc. before to choose libclamav or
clamd.
Best regards,
Janos
