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 TimeoutStartSec=<whatever> to the systemd service file. However, the upstream systemd service file (clamd/clamav-daemon.service.in) already sets TimeoutStartSec=420 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 [13] (x4) 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 ] real 12m55.235s user 12m47.843s sys 0m4.367s
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 real 1m14.430s user0m0.007s sys 0m0.003s
can someone with systemd test adding the line TimeoutStartSec=420 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 [Unit] Wants=freshclamd.service [Service] TimeoutSec=30min ``` Which so far, hasn't failed me :) (especially during boot, where many tasks can be running in parallel slowing this down a bit)
Linking the clamonacc ticket to this ; the resolution for both is to start shipping the upstream service files.
Resolved for 1.3.1-r1+
