freshclam error - !NotifyClamd: Can't find or parse configuration file /etc/clamav/clamd.conf

[Jānis Kangarooo]

Clamav recommends install new version from app, then sudo freshclam gives error- cant parse

kubuntu@kubuntu:~$ sudo freshclam
Fri Dec 15 22:57:56 2023 -> ClamAV update process started at Fri Dec 15 22:57:56 2023
Fri Dec 15 22:57:56 2023 -> ^Your ClamAV installation is OUTDATED!
Fri Dec 15 22:57:56 2023 -> ^Local version: 0.103.9 Recommended version: 0.103.11
Fri Dec 15 22:57:56 2023 -> DON'T PANIC! Read https://docs.clamav.net/manual/Installing.html
Fri Dec 15 22:57:56 2023 -> daily.cld database is up-to-date (version: 27124, sigs: 2048861, f-level: 90, builder: raynman)
Fri Dec 15 22:57:56 2023 -> main.cvd database is up-to-date (version: 62, sigs: 6647427, f-level: 90, builder: sigmgr)
Fri Dec 15 22:57:56 2023 -> bytecode.cvd database is up-to-date (version: 334, sigs: 91, f-level: 90, builder: anvilleg)

after installing LTS clamav-1.0.4.linux.x86_64.deb

kubuntu@kubuntu:~$ sudo freshclam
ERROR: Can't open/parse the config file /usr/local/etc/freshclam.conf

ProblemType: Bug
DistroRelease: Ubuntu 20.04
Package: clamav 0.103.9+dfsg-0ubuntu0.20.04.1
ProcVersionSignature: Ubuntu 5.8.0-43.49~20.04.1-generic 5.8.18
Uname: Linux 5.8.0-43-generic x86_64
ApportVersion: 2.20.11-0ubuntu27.16
Architecture: amd64
CasperMD5CheckResult: pass
CasperVersion: 1.445.1
CurrentDesktop: KDE
Date: Fri Dec 15 23:13:17 2023
LiveMediaBuild: Kubuntu 20.04.2.0 LTS "Focal Fossa" - Release amd64 (20210209.1)
SourcePackage: clamav
UpgradeStatus: No upgrade log present (probably fresh install)

[Athos Ribeiro (athos-ribeiro)]

This is likely a duplicate of LP: #2046581.

Hi Janis,

Where did you get clamav-1.0.4.linux.x86_64.deb from and how did you install it?

It seems you have a focal installation, where the latest clamav version is 0.103.9+dfsg-0ubuntu0.20.04.1.

Are you using a non-Ubuntu package for clamav ( suppose it is the upstream one)? If so, that is not a supported use case and you should get support with the package provider (e.g., upstream).

With that said, I wonder if we should get rid of this message in Ubuntu ("Your ClamAV installation is OUTDATED!") since it does not seem to be true from an Ubuntu perspective.

[Jānis Kangarooo (kangarooo)]

This is not duplicate. Other bug is about recomending to update something- database or app, i dont know.
This bug is when i updated app then i get this bug.
This version i got from link the terminal gave that i posted https://docs.clamav.net/manual/Installing.html

[Christian Ehrhardt  (paelzer)]

To be clear, As I understand it, bug 2046581 is about the "Your ClamAV installation is OUTDATED!" message.
And this one is about the complain that the .conf file isn't there.

Running freshclam manually as you did should usually not work and run into this:

ERROR: /var/log/clamav/freshclam.log is locked by another process
ERROR: Problem with internal logger (UpdateLogFile = /var/log/clamav/freshclam.log).
ERROR: initialize: libfreshclam init failed.
ERROR: Initialization error!

Because right after install it works and is active in the background.

root@f:~# systemctl status clamav-freshclam.service
● clamav-freshclam.service - ClamAV virus database updater
     Loaded: loaded (/lib/systemd/system/clamav-freshclam.service; enabled; vendor preset: enabled)
     Active: active (running) since Tue 2024-01-02 12:01:24 UTC; 11min ago
       Docs: man:freshclam(1)
             man:freshclam.conf(5)
             https://docs.clamav.net/
   Main PID: 3128 (freshclam)
      Tasks: 1 (limit: 38247)
     Memory: 7.0M
        CPU: 20.458s
     CGroup: /system.slice/clamav-freshclam.service
             └─3128 /usr/bin/freshclam -d --foreground=true

Jan 02 12:01:39 f freshclam[3128]: Tue Jan 2 12:01:39 2024 -> daily.cvd updated (version: 27142, sigs: 2050085, f-level: 90, builder: raynman)
Jan 02 12:01:39 f freshclam[3128]: Tue Jan 2 12:01:39 2024 -> main database available for download (remote version: 62)
Jan 02 12:02:03 f freshclam[3128]: Tue Jan 2 12:02:03 2024 -> Testing database: '/var/lib/clamav/tmp.4e9c5b0713/clamav-1136c9f80d7afd14a1faaf58bea4ac66.tmp-main.cvd' ...
Jan 02 12:02:10 f freshclam[3128]: Tue Jan 2 12:02:10 2024 -> Database test passed.
Jan 02 12:02:10 f freshclam[3128]: Tue Jan 2 12:02:10 2024 -> main.cvd updated (version: 62, sigs: 6647427, f-level: 90, builder: sigmgr)
Jan 02 12:02:10 f freshclam[3128]: Tue Jan 2 12:02:10 2024 -> bytecode database available for download (remote version: 334)
Jan 02 12:02:10 f freshclam[3128]: Tue Jan 2 12:02:10 2024 -> Testing database: '/var/lib/clamav/tmp.4e9c5b0713/clamav-5166218e129a54860e985aa9ae7009e1.tmp-bytecode.cvd' ...
Jan 02 12:02:10 f freshclam[3128]: Tue Jan 2 12:02:10 2024 -> Database test passed.
Jan 02 12:02:10 f freshclam[3128]: Tue Jan 2 12:02:10 2024 -> bytecode.cvd updated (version: 334, sigs: 91, f-level: 90, builder: anvilleg)
Jan 02 12:02:10 f freshclam[3128]: Tue Jan 2 12:02:10 2024 -> !NotifyClamd: Can't find or parse configuration file /etc/clamav/clamd.conf

All fine actually ...

Note, even seeing this is fine:
  !NotifyClamd: Can't find or parse configuration file /etc/clamav/clamd.conf

This is for the daemon, which many people have not installed (it consumed disk activity and CPU to scan in background).

If you'd also install the daemon you'd have it
$ apt install clamav-daemon
$ ll /etc/clamav/clamd.conf
-rw-r--r-- 1 root root 1994 Jan 2 12:43 /etc/clamav/clamd.conf

And it is ok to not notify a non installed daemon.

---

Only if you stop the service you can ever start it directly.
And even then it works on a clean install all is fine

root@f:~# systemctl stop clamav-freshclam.service
root@f:~# /usr/bin/freshclam
Tue Jan 2 12:45:29 2024 -> ClamAV upda...

[Bryce Harrington (bryce)]

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/clamd.conf

Perhaps it could simply state:

   No configuration file found at /etc/clamav/clamd.conf

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/etc/freshclam.conf

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://docs.clamav.net/manual/Usage/Configuration.html

[Bryce Harrington (bryce)]

@Jānis this bug and LP: #2046581 were discussed at today's server bug meeting. We sympathize at the confusion created by the log and warning messages, and agree the phrasing could be improved, however that would ideally be handled upstream. If you engage with upstream (or Debian) about this, share a link to the discussion for us to track from here.

Meanwhile, we'll leave this bug report open in our backlog, in case there is progress upstream or in Debian, or in case other people indicate they're also affected, in which case we will evaluate giving attention to it ourselves.