G.W. Haywood wrote:
Hi there,
Some time ago somebody wrote, and somebody else replied:
Why not just run freshclam as a daemon?
Then you really need to have a daemon watcher to keep it going.
Talk of freshclam dying gives me some discomfort, yet in almost two
years running freshclam as a daemon on two - not particularly busy -
servers I've never seen it fail. It uses around a megabyte of memory
on a machine with 2G of RAM and, doing hourly updates, it takes maybe
three seconds of CPU per month on a 1GHz twin-processor Pentium box.
Naturally if freshclam dies we can expect people to mention it. I'm
calling for those who run freshclam as a daemon and who don't see any
problems with it to chip into this thread. How many of us are there?
Here are the non-comment line in my config in case it has a bearing:
DatabaseDirectory /var/lib/clamav
UpdateLogFile /tmp/.clam/freshclam.log
LogVerbose
LogSyslog
PidFile /var/run/clam/freshclam.pid
DNSDatabaseInfo current.cvd.clamav.net
DatabaseMirror db.uk.clamav.net
DatabaseMirror database.clamav.net
MaxAttempts 5
Checks 24
Here's how I start it:
/usr/local/bin/freshclam -d --daemon-notify=/etc/mail/clamav/clamd.conf
Does anyone have any clues to the reasons behind freshclam's apparent
unreliability under some circumstances? Bad DB servers? Mail load?
Swap? Locking? Conflict with other processes? OS? Libraries? ...
--
73,
Ged.
_______________________________________________
Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net
http://lurker.clamav.net/list/clamav-users.html
The operation of freshclam is unrelated to the traffic volume of the
site so that is unimportant. It does only one job and it does it well. A
busy site only means it is a greater liability if it should fail or if
it should copy or produce flawed files, or fail to download new files.
But if you run it as a daemon in a production environment then it is a
simple best practice next step to monitor it and restart it should it
fail. You may have a different view of what is a best practice in this
regard (and it may even extend beyond freshclam) that leads you to
choose to run freshclam as a daemon without monitoring and watchdog
restart capability.
I can only tell you from my experience with several years and many
versions of ClamAV that I have found no advantage in any category to
running freshclam as a daemon, and running it in cron gives me many
options not otherwise available - not the least of which is I can run it
at random intervals to help break up lockstep assaults on the servers it
polls.
And as an old school Unix admin who still believes in the mentoring
responsibility of my position, I will make recommendations from time to
time regarding best practices and I recommend if you run freshclam as a
daemon that you monitor it and restart it if needed. Sun's SMF and other
methodologies (cfengine, watchdog) can do this trivially but fail to
do other checks of data integrity which must be scripted. So long as
clamd can be killed and left unable to restart because of the presence
of a corrupt or badly formated ndb file and since the db update process
requires scripting anyway it makes sense to me to wrap the freshclam
process and fetching other db's in cron driven scripts that:
Run at random intervals
Validate the databases that are downloaded including those that are not
collected by freshclam (Sane Security, MSRBL, for examples)
Move the validated files to the working directory
Test the new files against known samples
Retry on error or server failures
Notify the admin chain and log the error
This is not rocket science.
dp
_______________________________________________
Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net
http://lurker.clamav.net/list/clamav-users.html
