> -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > Eric Rostetter > Sent: Friday, October 03, 2008 12:20 PM > To: clamav-users@lists.clamav.net > Subject: Re: [Clamav-users] Stop it! > > Quoting Colin Alston <[EMAIL PROTECTED]>: > > > ClamAV has been continuously and repetitively adjusting > configuration > > options in such a way that breaks anything which is automatically > > upgraded just stops working. > > Well, maybe your "automatically upgrading" software needs improvment, > or just maybe you should follow standard best practices and not do > automatic upgrades on a critical/important production system? > > > This is further aggravated by the fact that Exim does not > know how to > > gracefully handle failures of clamav daemon. > > Maybe you need to talk to exim about this then?
Exim does exactly what it should when the clam daemon goes missing, it issues a temporary local problem deferral and logs the reason for it. I would hate to have the mailer deliver a potentially virulent message just because the daemon was dead. It even logs it in the panic log, which should never have an entry and should be checked 24/7 (simple cron script) and addressed immediately. > > > Is there a reason people feel it necessary to fail startup on old > > configuration options? > > Good question... > > > Is there a reason it can't at least log > > deprecations ahead of time to allow people to transition smoothly > > between versions *without* their entire mail service grinding to a > > halt? > > I doubt this is practical, and I doubt it would work well. > People who > do automatic upgrades and don't read the docs are not likely > to read and > understand log messages either. 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). The only way to see why it would not start was to run it in the foreground. This is 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. 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. > > > Is there a reason these options have to change at all, or that > > the configuration parser can't know about old options for > n versions > > and simply gracefully step over them? > > You are using a pre-release fast changing piece of software. Yes, it > will change. If you don't like that, wait for version 1.0 before you > use it. > > Yes, the parser could skip bad entries, but that would probably leave > users thinking that it was doing something that it wasn't, > which would > be bad (and would generate much list traffic). 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? > > > It's a line-for-line configuration system, startup does not need to > > fail at all when options are unrecognised! > > But if not, then the scanner may appear to work but be doing > something > quite different than intended. I mean, if it continued to run after > seeing unrecognized entries, which resulted in either a) all viruses > being passed through, or b) all files being marked as a virus whether > they are or not, that would be a bad thing. > > > I think ClamAV should be mature enough now to start respecting the > > users it has and try to behave in a somewhat more stable way. > > Let's see. You want it to be mature, but it hasn't even had > a 1.0 release? > That is an excuse not a reason. 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. 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. 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". 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 Rick -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. _______________________________________________ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml
