Temporary filesystems are cleaned (systemd-tmpfiles)
Require systemd-tmpfiles-clean.timer to be active, so /tmp and /var/tmp are aged out according to the tmpfiles.d rules instead of growing without limit. This pavois-native growth-* control follows the family rule: every filesystem pavois separates (and the pavois partition recipe separates /tmp and /var/tmp) must carry a mechanism that keeps it from filling.
Checked against the resolved running state (e.g. sshd -T, sysctl, systemctl show), catches drop-ins and Includes a file read would miss. Caveat: runtime ≠ persistence; a value correct now may not survive a reboot.
What Pavois checks
Pavois asks systemd for the timer's runtime state (systemctl is-active systemd-tmpfiles-clean.timer), which must be exactly active. A timer can be present on disk and still be disabled, masked, or simply never started: only the resolved state proves the cleanup will fire. The control audits the cleaner, not the current size of /tmp, because a /tmp that is empty today says nothing about the one that fills up in three weeks.
describe command('systemctl is-active systemd-tmpfiles-clean.timer 2>/dev/null') do
its('stdout.strip') { should eq 'active' }
endHow to verify it is applied
Check the timer and its next elapse, then dry-run the cleanup:
systemctl is-active systemd-tmpfiles-clean.timer
systemctl list-timers systemd-tmpfiles-clean.timer --all
systemd-tmpfiles --clean --dry-run
The dry run prints exactly which entries the next pass would remove, and under which tmpfiles.d rule.
Inspect & investigate
Every pass is logged by journalctl -u systemd-tmpfiles-clean.service, one line per removed path. That unit log is the audit trail: it shows what was deleted and when, which is what you need the day a service complains that its state file vanished from /tmp.
Remediation
Pavois manages systemd-tmpfiles-clean.timer as a service resource with the actions enable and start: the timer is enabled for the next boot and started in the running system, so the cleanup does not wait for a reboot. The ageing policy itself is not overridden: pavois relies on the distribution's tmpfiles.d rules (typically 10 days for /tmp, 30 for /var/tmp), which remain yours to tune.
Pavois applies this with its own harden engine, the plan below, not a shell script:
| action | enable, start |
|---|---|
| name | systemd-tmpfiles-clean.timer |
| resource | service |
pavois harden plan localwhere the target is local, a user@host SSH alias, or a container , Docs
Impact & precautions
Once the timer runs, files in /tmp and /var/tmp older than the configured age are deleted. Applications that (incorrectly) keep long-lived sockets, lock files or state under /tmp can break on the first pass. Inventory them before enabling, and move persistent state to /run (volatile) or /var/lib (durable), or carve an exemption with your own tmpfiles.d rule. This is the cheap end of a lesson the growth-* family learned the expensive way: a hardened host whose separate log filesystem reached 100% and powered the machine off six seconds into every boot, with every control green.