On slow systems clamav may struggle a bit to load the initial virus database file (time wise). Systemd however does not care and fails with a timeout, ending up in an infinite loop, as it tries to restart clamav. Not only that, a single core can be at 100% CPU load forever with clamd.
To solve this, we either need to let systemd know, clamd is still busy with starting, and hasn't crashed, or increase the timeout. Since the first is probably not easy, adding the TimeOut to the [Unit] section is the only available workaround.
As the timeout is highly system dependant, it is hard to find a useable value, but 5 minutes should cover nearly all use cases.
I can confirm that clamd takes ages to start these days ...
I do not know much about systemd .. can you provide a patch for the service files?
The short answer is to add something like
to the systemd service file. However, the upstream systemd service file (clamd/clamav-daemon.service.in) already sets
so in light of bug 662196, I think the way to solve this is to eventually drop our custom systemd service file, and use the one from upstream.
Unfortunately though, I am in the same situation as Thomas: no systemd here. So it will be hard to test the upstream service file. (It looks fine to me, but it uses a *third* service to create the clamd socket, so it's a nontrivial change.)
I can't add much systemd-wise, just saying that on my openrc-mailserver:
mail ~ # cat /proc/cpuinfo
processor : 0
vendor_id : AuthenticAMD
cpu family : 22
model : 48
model name : AMD GX-412TC SOC
stepping : 1
microcode : 0x7030105
cpu MHz : 960.624
cache size : 2048 KB
physical id : 0
siblings : 4
core id : 0
cpu cores : 4
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good acc_power nopl nonstop_tsc cpuid extd_apicid aperfmperf pni pclmulqdq monitor ssse3 cx16 sse4_1 sse4_2 movbe popcnt aes xsave avx f16c lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt topoext perfctr_nb bpext ptsc perfctr_llc cpb hw_pstate ssbd vmmcall bmi1 xsaveopt arat npt lbrv svm_lock nrip_save tsc_scale flushbyasid decodeassists pausefilter pfthreshold overflow_recov
bugs : fxsave_leak sysret_ss_attrs null_seg spectre_v1 spectre_v2 spec_store_bypass
bogomips : 1996.34
TLB size : 1024 4K pages
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management: ts ttp tm 100mhzsteps hwpstate cpb acc_power 
clamd takes about 12 minutes to start (pure SSD installation if that matters).
mail ~ # time /etc/init.d/clamd start
* Starting clamd ... [ ok ]
* Starting freshclam ... [ ok ]
Even for me, Clamav wasn't starting but updating virus database using freshclam worked for me.
Also, it took a minute to start the daemon
# time systemctl start clamd
can someone with systemd test adding the line
to the clamd service files and see if that works (and preferrably also set something way too low to make sure it works and bails then.
If that "solves" the issue I will commit a change to our service files with that line included.
As my server is quite old and slow (only 8GiB of ram, only 1.2GHz AMD Neo N36L CPU) I don't think 420 seconds will be enough.
For me, I use this for now:
7of9 /etc/postfix # cat /etc/systemd/system/clamd.service.d/override.conf
Which so far, hasn't failed me :) (especially during boot, where many tasks can be running in parallel slowing this down a bit)