You are not logged in.
When I try to start the clamav-clamonacc service after doing the suggested configuration of clamd.conf, it fails with the following reason in journalctl:
ERROR: Clamonacc: can't parse clamd configuration file @APP_CONFIG_DIRECTORY@/clamd.conf
The clamav service itself runs fine, so I don't see how it could be a syntax error of the clamd.conf file. Is it just not finding the configuration file due to that "@APP_CONFIG_DIRECTORY@"? How can I resolve this?
Offline
https://wiki.archlinux.org/index.php/Cl … AccessScan indicates you're not supposed to start that service directly.
After configuring /etc/clamav/clamd.conf , try restarting clamav-daemon.service
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline
https://wiki.archlinux.org/index.php/Cl … AccessScan indicates you're not supposed to start that service directly.
After configuring /etc/clamav/clamd.conf , try restarting clamav-daemon.service
That section is marked as outdated, so I was following the upstream: https://www.clamav.net/documents/on-access-scanning
For what it's worth, the clamav-daemon service has been restarted several times since I made the configuration changes.
Last edited by Hamsterkill (2020-11-22 22:25:40)
Offline
The upstream doc doesn't mention using systemd services at all, it expects users to manually start clamav / clamav-onaccess .
Have you tried disabling all clamav services and starting things manually as that guide suggests to verify that method works ?
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline
The upstream doc doesn't mention using systemd services at all, it expects users to manually start clamav / clamav-onaccess .
Have you tried disabling all clamav services and starting things manually as that guide suggests to verify that method works ?
The upstream documentation is presumably written that way as clamav, itself, supports non-systemd systems. It's not unusual for upstream documentations to be written in an agnostic way. Being an Arch user, translating that into systemd terms isn't usually that difficult. Here, it seems pretty clear that the clamav-clamonacc service is meant for the use of clamonacc.
To answer your question, clamonacc does start when run with
sudo clamonacc
-- which is to say it doesn't throw a parsing error as above. Though it seems unable to scan anything due to "Permission denied" errors.
EDIT: I should note that clamdscan has been unable to scan anything due to permission errors as well, whether or not clamd is started with systemd or manually. I'm guessing that's indicating the clamav user is misconfigured, but that's a separate issue from why the clamonacc service isn't starting.
EDIT2: Figured out the permission issue requires the use of --fdpass when running clamdscan or clamonacc. Clamonacc (when run manually) still can't successfully scan anything due to socket issues that appear to be the result of a bug in clamav currently.
I also looked into the clamonacc service. It seems that "@APP_CONFIG_DIRECTORY@" is some kind of variable meant to be replaced when the package is built, but that's not happening. I'll file a bug on Arch for it.
Last edited by Hamsterkill (2020-11-24 14:01:53)
Offline
well, here's the service in question
# clamonacc systemd service file primarily the work of ChadDevOps & Aaron Brighton
# See: https://medium.com/@aaronbrighton/installation-configuration-of-clamav-antivirus-on-ubuntu-18-04-a6416bab3b41#a340
[Unit]
Description=ClamAV On-Access Scanner
Documentation=man:clamonacc(8) man:clamd.conf(5) https://www.clamav.net/documents
Requires=clamav-daemon.service
After=clamav-daemon.service syslog.target network.target
[Service]
Type=simple
User=root
ExecStartPre=/bin/bash -c "while [ ! -S /run/clamav/clamd.ctl ]; do sleep 1; done"
ExecStart=/usr/sbin/clamonacc -F --config-file=@APP_CONFIG_DIRECTORY@/clamd.conf --log=/var/log/clamav/clamonacc.log --move=/root/quarantine
[Install]
WantedBy=multi-user.target
The 2nd ExecStart line has the --config-file=@APP_CONFIG_DIRECTORY@/clamd.conf part.
To me that looks like it should have been replaced by the real directory at build-time .
Checking upstream code at https://github.com/Cisco-Talos/clamav-d … service.in indicates clamav-clamonacc.service is not changed by archlinux pkgbuild.
To determine if this is an upstream error or a packaging bug requires further investigation.
Let's try to correct the mistake first.
Check https://wiki.archlinux.org/index.php/Sy … p-in_files and change the Execstart line so --config-file is set to /etc/clamav/clamd.conf
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline
Overriding the ExecStart line does allow the service to start properly. It won't scan anything, but that's due to the --fdpass bug I mentioned in an earlier edit along with the fact that argument is not being passed by the service. It seems like the @APP_CONFIG_DIRECTORY@ issue is likely a build bug on Arch's side though. I'll file a bug so they can investigate.
Offline
Overriding the ExecStart line does allow the service to start properly. It won't scan anything, but that's due to the --fdpass bug I mentioned in an earlier edit along with the fact that argument is not being passed by the service. It seems like the @APP_CONFIG_DIRECTORY@ issue is likely a build bug on Arch's side though. I'll file a bug so they can investigate.
Same issue, hope they fix that soon
Offline
Still nothing?
Offline
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline
Yeah. I was see that report at 1 month ago. Did they really can't fix such a trifle in a month?
Offline