Enable cron Service
Enables and starts the cron service so scheduled maintenance and security tasks run reliably.
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.
Pavois asserts the effective configuration, the live, resolved state, not a file. File-based scanners (OVAL/SCAP, Lynis) miss Includes, drop-ins and runtime defaults; this check sees what is actually applied.
A mapping is a cross-reference to where each standard places this requirement, anchored and cross-validated, not a claim of equivalence. A passing check is evidence toward these references, how to read it.
Why this rule matters
cron is the scheduler that runs periodic maintenance and security-supporting tasks, log rotation, package-cache updates, integrity checks, certificate renewals, and other hardening jobs. If the daemon is not running, these scheduled tasks silently stop, leaving the system unmaintained and potentially out of compliance. Keeping cron enabled is therefore essential to sustained security posture, not a convenience. (Debian/Ubuntu name the unit cron.service; RHEL uses crond.service.)
What Pavois checks
Pavois queries systemd for the effective state of cron.service (systemctl is-enabled / is-active), confirming the scheduler is both set to start at boot and currently alive. The presence of crontab files on disk says nothing about whether the daemon is actually running them, only the live service state confirms scheduled jobs will fire.
describe service('cron.service') do
it { should be_enabled }
it { should be_running }
endHow to verify it is applied
Confirm the unit is up:
systemctl is-enabled cron.service
systemctl is-active cron.service
Expect enabled and active. You can confirm jobs actually run by checking the logs after a scheduled task (see logs below).
Inspect & investigate
On Debian/Ubuntu, cron activity is in the journal: journalctl -u cron (and historically /var/log/syslog). Inspect the daemon with systemctl status cron.service. Each job run produces a CMD (...) line.
Remediation
Pavois's harden plan acts on the service resource named cron: it runs enable (start at boot) then start (run now). Applied with pavois harden apply. After it runs, scheduled jobs resume firing on time.
Pavois applies this with its own harden engine, the plan below, not a shell script:
| action | enable, start |
|---|---|
| name | cron.service |
| resource | service |
pavois harden plan localwhere the target is local, a user@host SSH alias, or a container , Docs
Impact & precautions
Misconfiguration risk: with cron stopped, maintenance and security jobs silently do not run, degrading the host over time. Precautions: enabling the scheduler will start executing whatever crontabs already exist, review /etc/crontab, /etc/cron.d/, /etc/cron.*/, and user crontabs first so no stale or unexpected job runs with surprising effect. Starting the service is otherwise non-disruptive and carries no lockout risk.
Standards mapping
| Standard | Reference | Type | Version | Confidence |
|---|---|---|---|---|
| CIS | 2.4.1.1 | direct | per OS, see the benchmark table | high |
| NIST | CM-6(a) | supporting | 800-53 Rev 5 · 800-171 Rev 2 (pinned) | medium |
Each reference is a cross-reference anchored in the upstream benchmark and cross-validated against the SCAP Security Guide and ansible-lockdown, not a claim of equivalence. Direct = a prescriptive, line-level requirement; supporting = an abstract control family (NIST) the check provides evidence toward. How to read a mapping.