Resolved Can't open /var/log/clamav/freshclam.log in append mode

[QWeb Ric]

We run 3 CentOS servers, each with Plesk.

At 4am this morning one of these servers triggered the following email:

/etc/cron.daily/0yum.cron:

warning: /etc/freshclam.conf created as /etc/freshclam.conf.rpmnew
warning: erase unlink of /var/lib/clamav/daily.cvd failed: No such file or directory
warning: erase unlink of /var/lib/clamav/bytecode.cvd failed: No such file or directory

And every hour has triggered the following:

/etc/cron.hourly/freshclam:

ERROR: Can't open /var/log/clamav/freshclam.log in append mode (check permissions!).

Presumably since the first error references Yum, Plesk must have brought in updates this morning that has for some reason messed up on just one of our servers (despite two of them being identical configurations).

I'm a little cautious about just changing the access perms, especially as the original error also references a couple of files that couldn't be deleted... any advice please?

Regards.

 

[Monty]

Just a wild guess (as we had a similiar issue some months ago): Do you have any other repos enabled (like epel or atomic) on your server?
If so, then maybe your previous ClamAV packages were replaced with the ones from another repo such as EPEL, or the other way round.

Check your /var/log/yum.log files for details.

You may have to reconfigure your ClamAV configuration and specify the correct username under which the services will run. In our case, the previous ClamAV package were using the user "clamavis" and the new ones from EPEL are now using the user "clamupdate" (for /var/lib/clamavis).

The cleanest solution is to erase all clam* packages and install them fresh, using new configuration files.

 

[QWeb Ric]

Thanks Monty,

We do have both epel and atomic installed so this could well be what's happened. They're also installed on one of our other servers though, which isn't erroring, and that got me thinking...

These servers are meant to be identically configured but having checked the above, I then thought to look into the cron jobs to see if you were right about them being set up with different users (I figured the bash script would tell me where the config file was). In doing that I discovered /etc/cron.hourly/freshclam doesn't exist on the server that isn't erroring, which would explain why this is only affecting the one server (doh!).

I then checked the Plesk configs and couldn't see any reference to Clam packages under either. I was expecting that Clam had been brought in via Plesk hence posting here - turns out I'm wrong about that. In fact a grep of the console history shows that we manually installed Clam some time ago, to do a scan of something, and never actually set it up to run regular scans - it's just been sitting there using up hourly cycles to bring updated definitions which is what's now failing.

Long story short, I've just removed Clam from this server. We already have virus protection for email accounts through Plesk and the websites we host are all built internally, or at least supervised internally, so it seems silly to throw more resources at virus scans anyway really.

Thanks again, and sorry that this turned out to be completely unrelated to Plesk in the end!