© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
7020100
(Get the code!)
As Christian notes the clamd.conf is installed by the clamav-daemon binary package, so if that's not installed then other parts of clamav will issue warnings about it when run, even though those parts otherwise seem to behave properly.
I can see how the user experience here is a bit confusing. Debian's bug #867877 also alludes to this, on a somewhat different config-related issue, discussing about potentially needing better docs.
So regarding the config file error message, i.e.:
!NotifyClamd: Can't find or parse configuration file /etc/clamav/
Perhaps it could simply state:
No configuration file found at /etc/clamav/
In googling about for docs on using clamav, it's not unusual for the user to be told to run `sudo freshclam` directly, and in this situation the error messages printed (shown in Christian's comment) are accurate but may lead to confusion for folks not already knowledgeable in systemd operation. Perhaps that could explicitly state that the conflicting process is the systemd service? E.g. that freshclam is already being run, and that doing so manually requires shutting down the service?
I've not looked into how invasive it would be to patch these changes in, nor whether the changes might be acceptable in Debian or upstream, however we already carry one piece of delta to quell a confusing error message, "id: ‘clamav’: no such user", for LP: #1920217. So quelling more warnings would not be unprecedented...
Lastly, regarding this error message:
ERROR: Can't open/parse the config file /usr/local/
As others already noted, this appears to be due to installing the non-Ubuntu deb from upstream - we don't (yet) ship 1.0.4, and the official packages install to /usr not /usr/local. Looking at their download page, they provide a single binary .deb, which is different from Debian/Ubuntu where various components are divided out to their own .debs. So their packaging may be quite different from ours and may have different design intent for how things are expected to be configured. So, if you prefer to run from upstream's packaging, that you also follow upstream's configuration docs: https:/