[EMAIL PROTECTED] wrote: > Oh, I completely agree, that's my job. But if clam has stability > issues, that needs to be addressed in clam. clamd->clamscan failover > code would be short and sweet and the addition to clamdscan would be > minimal compared to the cost of a complete code audit for clamd. The > mail watchdog would be specific to our server and I am not inferring > that any of you should write it. Either way, if clamd is buggy, it > should not be my duty to build a workaround but I will if clamd hasn't > stabilized.
My turn to agree. Obviously, if there are stability issues, then the only place that can be addressed is within the software itself. Although, I will be honest, I have never had a single (crash|lockup|instability) with Clam. I still do believe, however, that any monitoring/fallback should be external to Clam. A shell, perl, python or whatever script is more customisable per system/platform. At the end of the day, if you have a failsafe built into software which is monitoring for it's own bugs or problems, what is to say the monitoring/fallback code may be not be susceptible to the problems it is guarding against? :) I personally have no type of monitoring running with Clam, for as I mentioned earlier, it has been rock solid for me. Matt _______________________________________________ http://lists.clamav.net/cgi-bin/mailman/listinfo/clamav-users
