Closed mwerle closed 8 months ago
Wed Feb 28 22:36:27 2024 -> WARNING: Your ClamAV installation is OUTDATED! Wed Feb 28 22:36:27 2024 -> WARNING: Local version: 0.103.10 Recommended version: 0.103.11
These are just warning messages. It is non-fatal.
I cannot tell from your logs why your clamd
service is not running and listening to the /var/run/clamav/clamd.ctl
socket.
Sorry, but it's the only reason I can find in the logs. Restarting clamav and recreating the socket causes the same issue; exim4 unable to connect to the clamav socket.
(ED; thank you for your fast reply, btw)
The warnings are from freshclam
, the signature database updater.
What happens in your logs when you try starting clamd
?
Edit: That is, please check /var/log/clamav/clamav.log
What happens in your logs when you try starting clamd?
clamav starts normally except for this warning and (re)creates its socket in /var/run/clamav (which I manually deleted to test it)
So... it's working now?
clamav is running, but exim4 cannot connect to the clamav socket. (I restarted exim4 as well). Hence I assumed it was due to the outdated version as I can't see anything else wrong.
(which I manually deleted to test it) ... clamav is running, but exim4 cannot connect to the clamav socket.
Have you since restarted clamd without deleting the socket file so that exim can open it?
If /var/run/clamav/clamd.ctl
exists and exim4 can't open it, then perhaps it is a permissions issue with the socket file, or the user/groups that exim4 is running with?
Can you tell if the exim4 user/process has read/write permissions for /var/run/clamav/clamd.ctl
?
Yes, my first steps were to restart clamav, freshclam, and exim4. (I did this several times, including manually deleting the clamav socket to ensure clamav would recreate it)
Since that didn't fix the situation I started looking into log files; the only issue I saw was the OUTDATED
warning. My apologies if I jumped the gun with this issue, but it's the only reason I could see for it breaking. My server currently has an uptime of over 500 days, and I haven't modified anything for many months. It does run daily updates, although is running Debian 11.. on my backlog to make some time to upgrade it.
Can you tell if the exim4 user/process has read/write permissions for /var/run/clamav/clamd.ctl? Everybody does:
root@boa:/var/log/clamav# ls -la /var/run/clamav/ total 0 drwxr-xr-x 2 clamav root 60 Feb 28 23:29 . drwxr-xr-x 37 root root 1120 Feb 28 10:26 .. srw-rw-rw- 1 clamav clamav 0 Feb 28 23:29 clamd.ctl
Do you see any errors or warnings or anything in /var/log/clamav/clamav.log
? I'm not sure where else to look for clues.
How much RAM does your system have? We really ought to add this to our clamconf -n
output so I wouldn't have to ask. Perhaps there's some issue with clamd
running out of memory. The signature database appears to require ~1.3GB these days just to start, which means it would use at least 2.6GB on reload + any memory used during a scan, on top of RAM requirements for other software.
Plenty of RAM, using about 4/12GB); system has never used swap that I'm aware of.
As for the OUTDATED
, I am terribly sorry, but it appears that I've jumped the gun on this issue - I've now looked further back in the logs and see that freshclam has been reporting this warning for a while now, so it's certainly not the root cause of my current issue. So I'll close this bug as it's not actually the cause.
If I track down the cause I'll add a note here.
Thank you for your help and suggestions of where else to look for the issue. I've disabled clamav for now just so I can get emails flowing again and will see about updating the OS; it's been on my TODO for a while now anyway.
So sorry we couldn't nail down the root cause. Best of luck.
Describe the bug
Outdated clamav causes exim4 to reject all incoming emails.
THIS IS NOT ACCEPTABLE! Yes, for sure, there must be a warning, but it MUST NEVER break the entire email delivery system.
Relevant exim config:
Exim log:
Freshclam log:
How to reproduce the problem
No particular steps required; just have a long-running server.