Enable cron Service
Enables and starts the crond 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
crond is the scheduler that runs periodic maintenance and security-supporting tasks, log rotation, package-database updates, integrity checks, antivirus scans, 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 crond enabled is therefore essential to sustained security posture, not a convenience.
What Pavois checks
Pavois queries systemd for the effective state of crond.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('crond.service') do
it { should be_enabled }
it { should be_running }
endHow to verify it is applied
Confirm the unit is up:
systemctl is-enabled crond.service
systemctl is-active crond.service
Expect enabled and active. You can confirm jobs actually run by checking the cron log after a scheduled task (see logs below).
Inspect & investigate
Cron execution is logged to /var/log/cron on the RHEL family (or via journalctl -u crond). Inspect the daemon with systemctl status crond.service. Each job run produces a CMD (...) line in the cron log.
Remediation
Pavois's harden plan acts on the service resource named crond: 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 | crond.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 crond 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/, 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 |
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.