On Wed, 27 Oct 2004, Joe Maimon wrote:
The ClamAV authors could put a stop to this by making clamdscan and clamscan the same program and then acting differently depending on which name is run. This is similiar to how gzip and gunzip are
This has been brought up before and I am surfacing it again because there
was some interest and it would add to the stability of ClamAV. Very
simply, clamdscan needs to timeout the connection to clamd after some
(sane) amount of time and run clamscan. An action could then be taken to
alert someone if clamd died (|sendmail [EMAIL PROTECTED]). When clamd
hangs on our system, mail is deferred until I realize mail has stopped and as you can imagine, that is a bad thing. Someday I'll write a mail-server watchdog w/ procmail and cron but I've not had time.
Any thoughts on how this should be accomplished?
In the clamav distribution contrib tree there is a clamwatch script (perl). It uses Unix or tcp sockets, your call. It returns 1 if clamd is running, 0 if anything bad happens. This is far better than checking only the process table (pgrep clamd or ps -ef |grep [c]lamd) as it actually tests for a known pattern, the Eicar test signature and of course exercises the entire tool.
This can be run out of cron via a shell script wrapper, of course, and the return results used to run clamscan or restart clamd or let you know via email/pager that something is broken. Or all of this. Though I don't know how you might hand off the file handle without jiggering the milter or script.
I use Sendmail and a third party milter (J-Chkmail) and just restart clamd if things are not right. It's not happened since 0.75.1 was released. My system is configured to tempfail the message if the milter/scanner fails and this gives me a second chance to look at the message when, hopefully, things are in better shape (hasn't happened yet)
dp .. knock on wood _______________________________________________ http://lists.clamav.net/cgi-bin/mailman/listinfo/clamav-users
