[Pkg-clamav-devel] Bug#748310: clamav-daemon: initscript ignores configfile name at daemon start

Andreas Cadhalpun andreas.cadhalpun at googlemail.com
Mon May 19 22:01:48 UTC 2014


Control: tags -1 -moreinfo
Control: tags -1 pending

Hi Peter,

On 19.05.2014 21:29, Peter Gervai wrote:
> On Mon, May 19, 2014 at 7:19 PM, Andreas Cadhalpun
> <andreas.cadhalpun at googlemail.com> wrote:
>
>> Why should this be necessary?
>> CLAMAVCONF=/etc/clamav/clamd.conf is the default location, where clamd looks
>> for a configuration file. Or did you change CLAMAVCONF and if so, why?
>
> Obviously. :-)
>
> The machine is part of a cluster and the cluster have more than one
> moving clamav server instances. If there's a problem with a
> clamav-hosting cluster member its clamav (along with its IP and
> config) moves over to the other cluster hosts, so it's possible that
> one host runs more than one clamav (on different IP addresses). Due to
> pid and locking issues (and some generalisations) it's much easier to
> have multiple configs than trying to manually set various parameters.
>
> But if you look at your script it partially written as being able to
> use any config file so the careless reader (like I was) would think it
> will work for other config names, which isn't true.  You could,
> obviously, remove any variables containing the config file but my
> suggestion may be more useful for the general happiness of the
> sysadmins.

Now I see. I think the intention of the $CLAMAVCONF variable was, to 
make it easy to adapt the script, when the default location of the 
configuration file changes.
But since the change you proposed doesn't do any harm and apparently has 
a usecase, I commited it to the repo [1].

>>> Apart from that it isn't quite LSBish that the initscript bails out
>>> when config is
>>> set to foreground and there's no 'daemon' installed, even on help or
>>> status
>>> requests. It's pretty impolite towards a clusering infrastructure for
>>> example.
>>
>>
>> I'm not aware of any 'help' request that the init script should handle, and
>> for the status request, the error message gives the status, i.e. that there
>> is a configuration problem.
>>
>> Or what status message would you expect in that case?
>
> Basically http://clusterlabs.org/doc/en-US/Pacemaker/1.0/html/Pacemaker_Explained/ap-lsb.html

Do I understand you correctly that you want the return codes to be changed?

Best regards,
Andreas

1: 
http://anonscm.debian.org/gitweb/?p=pkg-clamav/clamav.git;a=commitdiff;h=0397b225698b31ca80ed123fc636661f949f4528



More information about the Pkg-clamav-devel mailing list