ReceiveTimeout=30 is probably the one causing you problems. I was
bitten by that when installing ClamAV on an Ubuntu-based system last
year. For me, on a ~16Mpbs downlink home broadband connection, it took
longer than that to download the signatures, so would repeatedly time
out and retry. I think in that case the retries occur every 5 seconds,
regardless of other settings specifying the frequency of update checks,
since it hadn't actually successfully updated. As I understand it,
checking every hour shouldn't usually be a problem - its the retries
triggered by the timeout that cause the rate-limiting to kick in.
Having mentioned it here myself almost a year ago myself, it turns out
that the default built into ClamAV sets ReceiveTimeout=0, which means no
timeout. However, the Ubuntu 16.04 and 18.04 packages create an initial
configuration with it to 30. I think the Ubuntu 20.04 packages now set
it to 0, the same as ClamAV's default, but it may be that you've
inherited a configuration from an older installation - or perhaps KDE
Neon provide their own packages with the default still set to 30. So it
seems that 30s default isn't actually the ClamAV team's fault.
What does seem to exacerbate the problem is that, when the download
times out, it retries after 5 seconds so you quickly get blocked by the
rate-limiting and have to wait for that to reset before trying again
after fixing the config. But, as was explained to me, there are some
cases where retrying immediately makes sense and freshclam can't
necessary determine that, so always waiting a longer period (or until
the next update check is due) isn't necessarily the right thing to do
either (and in its default configuration a timeout wouldn't happen anyway).
Mark.
Jerzy Witwinowski via clamav-users wrote:
@ Maarten Broekman - I'm using the version 0.103.5 which, I think, is
the current version in KDE Neon repos (KDE Neon being based on Ubuntu
20). But what I did yesterday (manual tuning of the configuration file,
lowering the number of times per day the updates are fetched and
increasing the receive timeout) helped. This evening, when I started my
computer after returning from work, I checked the version of the virus
database and saw that ClamAV had managed to update it.
@ G.W. Haywood - Hopefully after manual tweaking of the config file
everything works again as it should (as I explained in my answer to
Maarten Broekman above). And it's not that I've been neglecting the
security... It's just that as everything had been working smooth and
fine since I've installed ClamAV many years ago, I've stopped manually
checking if everything was still OK (because why would it stop working
after all those years?)... My bad.
Anyway, three things:
1. I would like to apologize for writing BEFORE I could verify if the
manual tweaks would work once my cool-down period lifted.
2. Thank you all for your patience and your help.
3. There is still one question that puzzles me: why the default
configuration of ClamAV (checking for updates every hour, Retrieve
Timeout set to 30) is designed in a way that leads directly to the ban
by the CDN and renders the software useless?
_______________________________________________
clamav-users mailing list
clamav-users@lists.clamav.net
https://lists.clamav.net/mailman/listinfo/clamav-users
Help us build a comprehensive ClamAV guide:
https://github.com/vrtadmin/clamav-faq
http://www.clamav.net/contact.html#ml
_______________________________________________
clamav-users mailing list
clamav-users@lists.clamav.net
https://lists.clamav.net/mailman/listinfo/clamav-users
Help us build a comprehensive ClamAV guide:
https://github.com/vrtadmin/clamav-faq
http://www.clamav.net/contact.html#ml
