Quoting Rick Cooper <[EMAIL PROTECTED]>: > > Maybe you need to talk to exim about this then? > > Exim does exactly what it should when the clam daemon goes missing, it
I was going by the original posters comment that exim "does not know how to gracefully handle failures of clamav daemon." Since exim does apparently handle them appropriately, then my comments should be ignored, since they were responding to a false statement. > Ahh but therein lies the real issue. clamd just doesn't start, no logging at > all (at least not with the problem that appeared in .94). Okay, so the valid critique is that it should log an error when it fails to startup, not that it should fail to startup if the configuration file is invalid. > absolutely *wrong*. Clamd is a daemon, if it can output to stderr in > foreground mode it should most certainly out put to the log in daemon mode. Assuming there is no reason it can't (failed hard drive, etc), then this is reasonable. > If you are going to program a daemon to die if it doesn't understand a > configuration item (which I think is wrong as well) it should at least wait > until it has attempted to connect to the log and issue a big boldfaced > reason for it's refusal to start. I have no problem with this. Note that this is a far cry from saying that it shouldn't die on a bad config file, which was the original complaint. > Log the error and then abuse the SysOp that missed the log output, don't > abuse the operator that get's no feed back from the program what so ever > when run as intended (daemon), where does that leave anyone? I have no problem with your position that it should log an error. But this is a totally separate issue from the question of should it run if the configuration file is bad. > That is an excuse not a reason. It is a reason why the original poster should not be complaining in the way being done. > ClamAV has been around more than long enough > for on to at least expect if it's going to intentionally die it will log the > reason before doing so. Yes, I have no problem with this. But the original complaint was that it died at all, and the original solution was that it should run no matter what. This is a far cry from "it should log a message if it is going to die on purpose." > I say intentionally because I cannot think of any > reasonable excuse as to why it would die because it doesn't understand a > line in the configuration file unless the programmer specifically intends > that it should. I agree, it is doing so on purpose, and hence intentionally. > ClamAV might not technically be a release version yet but it is well known > to be widely used and I never use versions that are not released as > "stable". That is a contradiction. I think you mean "generally perceived as stable" rather than "released" as stable. > The clam team (as evidenced by the official website) is proud of > the wide spread usage with mail systems but with that acceptance by the > community comes a certain responsibility (even with free software) and a > daemon that dies without any notice is a fundamental flaw that should really > be addressed, just my opinion I agree. But this is a completely separate issue from the original posting. > Rick -- Eric Rostetter The Department of Physics The University of Texas at Austin Go Longhorns! _______________________________________________ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml
