nice -n 19 only yields when other processes compete; on single-core VPS boxes the scan still saturates CPU. Document the expectation. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
89 lines
2.5 KiB
Markdown
89 lines
2.5 KiB
Markdown
---
|
||
title: ClamAV Safe Scheduling on Live Servers
|
||
domain: troubleshooting
|
||
category: security
|
||
tags:
|
||
- clamav
|
||
- cpu
|
||
- nice
|
||
- ionice
|
||
- cron
|
||
- vps
|
||
status: published
|
||
created: 2026-04-02
|
||
updated: 2026-05-11T18:31
|
||
---
|
||
# 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:
|
||
|
||
```cron
|
||
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`:
|
||
|
||
```cron
|
||
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:
|
||
|
||
```bash
|
||
crontab -e
|
||
```
|
||
|
||
Or apply non-interactively:
|
||
|
||
```bash
|
||
crontab -l | sed 's|clamscan|nice -n 19 ionice -c 3 clamscan|' | crontab -
|
||
```
|
||
|
||
Verify:
|
||
|
||
```bash
|
||
crontab -l | grep clam
|
||
```
|
||
|
||
## Diagnosing a Runaway Scan
|
||
|
||
If CPU is already pegged, identify and kill the process:
|
||
|
||
```bash
|
||
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.
|
||
|
||
## Related
|
||
|
||
- [ClamAV Documentation](https://docs.clamav.net/)
|
||
- [Linux Server Hardening Checklist](../../02-selfhosting/security/linux-server-hardening-checklist.md)
|