Skip to content

ClamAV Safe Scheduling on Live Servers

Running clamscan unthrottled on a live server will peg CPU until completion. On a small VPS (1 vCPU), a full recursive scan can sustain 70–100% CPU for an hour or more, degrading or taking down hosted services.

The Problem

A common out-of-the-box ClamAV cron setup looks like this:

0 1 * * 0 clamscan --infected --recursive / --exclude=/sys

This runs at Linux's default scheduling priority (nice 0) with normal I/O priority. On a live server it will:

  • Monopolize the CPU for the scan duration
  • Cause high I/O wait, degrading web serving, databases, and other services
  • Trigger monitoring alerts (e.g., Netdata 10min_cpu_usage)

The Fix

Throttle the scan with nice and ionice:

0 1 * * 0 nice -n 19 ionice -c 3 clamscan --infected --recursive / --exclude=/sys
Flag Meaning
nice -n 19 Lowest CPU scheduling priority (range: -20 to 19)
ionice -c 3 Idle I/O class — only uses disk when no other process needs it

The scan will take longer but will not impact server performance.

Applying the Fix

Edit root's crontab:

crontab -e

Or apply non-interactively:

crontab -l | sed 's|clamscan|nice -n 19 ionice -c 3 clamscan|' | crontab -

Verify:

crontab -l | grep clam

Diagnosing a Runaway Scan

If CPU is already pegged, identify and kill the process:

ps aux --sort=-%cpu | head -15
# Look for clamscan
kill <PID>

Notes

  • ionice -c 3 (Idle) requires Linux kernel ≥ 2.6.13 and CFQ/BFQ I/O scheduler. Works on most Ubuntu/Debian/Fedora systems.
  • On multi-core servers, consider also using cpulimit for a hard cap: cpulimit -l 30 -- clamscan ...
  • Always keep --exclude=/sys (and optionally --exclude=/proc, --exclude=/dev) to avoid scanning virtual filesystems.
  • 1 vCPU limitation: nice and ionice only help when other processes compete for resources. On a single-core VPS, clamscan will still saturate the CPU at 57-100% even with nice -n 19 ionice -c 3 — there's nothing to yield to. Accept the weekly spike as benign, or reduce scan scope to shorten the window.