ClamAV throwing repeated warning messages

Support for security such as Firewalls and securing linux
Post Reply
Posts: 1
Joined: 2020/07/01 19:01:54

ClamAV throwing repeated warning messages

Post by amclean17 » 2020/07/01 19:04:46

I'm trying to install ClamAV on AWS EC2 instances running CentOS 7. I have on-access scanning enabled in notify-only mode, so OnAccessPrevention is turned off.

It all works, but the log files are rapidly filled with warning messages. Can't exactly point Splunk to a log file that messed up.

clamonacc logs this message:

Code: Select all

`ClamMisc: $/proc/8086 vanished before UIDs could be excluded; scanning anyway`  
The number is different in most entries, but the message is the same, prints over and over fast as it can. I find this a bit strange because I've tried adding /proc/ to excluded directories.

clamd logs this message:

Code: Select all

`WARNING: lstat() failed on: /opt/splunkforwarder/etc/apps/xxxxx/bin/`  
I can't disclose some of that directory, hence the xxxxx, but it logs this for most everything under /opt/splunkforwarder/ and a few files under /home/ too.

clamd is running under the service account clamscan, clamonacc is running as root (although I'm wondering if perhaps it shouldn't)

Any ideas on a way to stop these messages?

David H Open
Posts: 1
Joined: 2020/08/24 09:22:44

Re: ClamAV throwing repeated warning messages

Post by David H Open » 2020/08/24 09:52:08

Hello, I have had the same experience and chosen the following solution.

I am supposing from your description that you have applied the "Use Case 0x0" configuration recipe from with OnAccessMountPath / and some user exclusions (including perhaps excluding root). Also you confirmed that OnAcessPrevention was off. Therefore, as far as I can make out, the reason for the message that is appearing in the logs is given in the comment documentation for OnAccessExcludeUID in /etc/clamd.d/scan.conf:

Code: Select all

# Also note that if clamd cannot check the uid of the process that generated an
# on-access scan event (e.g., because OnAccessPrevention was not enabled, and
# the process already exited), clamd will perform a scan.  Thus, setting
# OnAccessExcludeUID is not *guaranteed* to prevent every access by the
# specified uid from triggering a scan (unless OnAccessPrevention is enabled).
You said "I've tried adding /proc/ to excluded directories"; if you tried to do this with OnAccessExcludePath, that won't work with OnAccessMountPath. From what I understand of the documentation, OnAccessMountPath uses a certain kernel fanotify configuration giving it efficient notifications of all access events in entire filesystems. Whereas OnAccessExcludePath works with OnAccessIncludePath, which uses ClamAV's "DDD" system based on a different fanotify configuration. In my case I found that OnAccess{Include,Exclude}Path / DDD was prohibitively expensive CPU-wise.

Personally I tried multiple OnAccessMountPath directives limited to various folders (mainly root ones) without mentioning / or /proc . This did not work: I suppose it confirms that OnAccessMountPath works for entire filesystems and that trying to target subfolders only, even root ones, just includes the entire filesystem they are part of (so in my case, I suppose that OnAccessMountPath /usr sort of implied OnAccessMountPath /, since /usr was not a separate filesystem, and that in turn meant that /proc was being monitored again).

At the end of the day I decided to simply silence clamonacc's standard output. That is where the message is coming from. Unfortunately, simply adding --log=/dev/null to the commandline in clamonacc.service's Unit File did not work. I had to do it at the systemd level, with the StandardOutput=null directive in the [Service] section. I am automating such configuration so I did it as properly as I could, leveraging systemd's Unit File snippet system with the "edit" command (it creates a /etc/systemd/system/clamonacc.service.d/override.conf file and automatically does daemon-reload so the file will be merged, prioritarily, with the standard /usr/lib/systemd/system/clamonacc.service); and because systemctl edit would normally use an interactive editor such as vi for the job, precluding a standard input heredoc, I overrode SYSTEMD_EDITOR (kudos to

----- TL;DR start here -----

Code: Select all

sudo SYSTEMD_EDITOR=tee systemctl edit clamonacc.service << 'EOF'
I'm hoping that silencing only the standard output from clamonacc, which is run as --foreground in the Unit File service definition provided for CentOS, will not prevent true error conditions from appearing in the system logs from its standard error output. Also infection detections are logged separately by the clamd@scan service anyway.

Post Reply

Return to “CentOS 7 - Security Support”