majorwiki/05-troubleshooting/security/freshclam-logwatch-false-no-updates.md
MajorLinux d8f07e8e2e wiki: add ClamAV freshness watchdog + sendmail (not mail) alert guidance
Document the daily /etc/cron.daily/clamav-freshness watchdog as the real
detector for stale signatures, and the key gotcha that 'mail' is absent on
most fleet hosts so alert scripts must use /usr/sbin/sendmail -t.
2026-06-06 07:17:56 -04:00

80 lines
4.7 KiB
Markdown

---
title: "Logwatch Falsely Reports 'No freshclam updates' in ClamAV Daemon Mode"
domain: troubleshooting
category: security
tags: [clamav, freshclam, logwatch, false-positive, fedora, ubuntu, ansible]
status: published
created: 2026-06-06
updated: 2026-06-06
---
# Logwatch Falsely Reports "No freshclam updates" in ClamAV Daemon Mode
Logwatch's daily `clam-update` section emails:
> No updates detected in the log for the freshclam daemon (the ClamAV update process). If the freshclam daemon is not running, you may need to restart it.
…even though freshclam **is** running and signatures **are** current. It's a parser quirk specific to running freshclam as a daemon. Don't act on the "restart it" suggestion — first confirm whether signatures are actually stale.
> Seen on **tttpod** (2026-06-06). All four freshclam hosts (majorlinux, majortoot-hetzner, teelia, tttpod) hit this on quiet days.
## First: is it real or false?
```bash
systemctl is-active clamav-freshclam # active?
ls -l /var/lib/clamav/daily.c[lv]d # mtime today/yesterday?
grep 'updated' /var/log/clamav/freshclam.log | tail # real download events
```
- **Fresh `daily.cld` + active service → false positive** (this page).
- **`daily.cld` weeks old / service disabled → real.** Re-enable freshclam and update (see Related). A daemonless box still needs freshclam enabled — `clamav_use_daemon: false` only disables the *scanner* daemon, not the updater.
## Why It False-Alarms
logwatch's `clam-update` script (`/usr/share/logwatch/scripts/services/clam-update`) decides "updated" by counting **`ClamAV update process started`** lines (`$UpdatedNum`) within its range (`Range = yesterday`). It does **not** count the actual `daily.cld updated (version: …)` download lines.
freshclam emits "update process started" **only when the daemon (re)starts** — not on its periodic in-daemon checks (`Checks 24`, `ExecStart=/usr/bin/freshclam -d`). So on any day the box doesn't reboot or restart freshclam, yesterday's log has zero "started" lines → `$UpdatedNum == 0` → the warning fires, regardless of whether signatures downloaded. (Conversely, on a day you *do* reboot, the warning won't fire.) The script was written for the old cron-driven freshclam, which started a fresh process each run.
## Fix
Silence just that one message — real `ERROR` / `WARNING` / outdated alerts still report:
```bash
# /etc/logwatch/conf/services/clam-update.conf
$ignore_no_updates = 1
```
No service restart needed; logwatch picks it up on its next daily run. (The variable is read as `$ENV{'ignore_no_updates'}` by the script — note: **not** prefixed `clam_update_`, despite what the script's own self-help text suggests.)
## Codify (Ansible)
Deploy the drop-in wherever freshclam runs in daemon mode. On the fleet it's a task in `configure_clamav.yml` (group `clamav`), right after freshclam is enabled — MajorAnsible commit `cb27c93`:
```yaml
- name: Suppress logwatch clam-update false "no updates" alert (daemon-mode freshclam)
ansible.builtin.copy:
dest: /etc/logwatch/conf/services/clam-update.conf
mode: '0644'
content: |
$ignore_no_updates = 1
tags: [logwatch]
```
## Key Notes
- **Confirm freshness before suppressing.** If signatures really are stale (freshclam off / no update timer), suppressing hides a genuine security gap. On a daemonless host that disabled freshclam, the warning is *true*.
- The script's built-in options B/C (about syslog format) don't apply when freshclam logs to its own file (`LogSyslog false`); `$ignore_no_updates` is the right lever.
- **Don't alert with `mail`.** The `mail`/`mailx` CLI is absent on most fleet hosts (only Postfix's `/usr/sbin/sendmail` is guaranteed). A health script that ends in `mail -s … root` silently fails to send. Pipe a headered message to `/usr/sbin/sendmail -t` addressed to `admin_email` directly (don't rely on an `/etc/aliases` `root` rewrite either).
## Proactive monitoring (don't rely on logwatch for "is it updating?")
Since logwatch's heuristic is suppressed, a **direct daily watchdog** is what actually catches a dead freshclam. `configure_clamav.yml` deploys `/etc/cron.daily/clamav-freshness` (MajorAnsible `9d1a1a9`) to every `clamav`-group host: it emails the admin (via `sendmail`) if `clamav-freshclam` is inactive **or** `daily.cld` is older than `clamav_staleness_threshold_days` (default 3) — and stays silent otherwise. Test without emailing:
```bash
CLAMAV_STALE_DAYS=0 /etc/cron.daily/clamav-freshness # forces the stale branch
```
This is what would have caught dcaprod's 20-day drift immediately instead of it surfacing by accident.
## Related
- [ClamAV CPU Spike: Safe Scheduling with nice/ionice](clamscan-cpu-spike-nice-ionice.md)