← All rules
SOCLE-RUN-SVC-034// systemd servicesmediumeffective runtime

Enable systemd-journald Service

Ensures the core logging service systemd-journald.service is enabled and running so kernel, service, and application logs are captured.

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.

A pass proves✓ running now? on disk? survives rebootthe qualified verdict →
Debian 12CIS 1.1.0Debian 13CIS 1.0.0FedoraRHEL 10 / Rocky 10 / AlmaLinux 10RHEL 8 / Rocky 8 / AlmaLinux 8CIS 4.0.0RHEL 9 / Rocky 9 / AlmaLinux 9CIS 2.0.0Ubuntu 22.04CIS 3.0.0Ubuntu 24.04CIS 1.0.0Ubuntu 26.04
One check, maps to 2 standards

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

systemd-journald is the core logging service that collects and stores structured log data from the kernel, services, and applications. In the event of a system failure, the system must preserve the information needed to determine the cause and to return to operation with the least disruption. If journald is not running, no journal is captured: security events go unrecorded, post-incident forensics are impossible, and other tools (rsyslog, journal-upload, audit forwarding) that depend on the journal lose their source. Reliable logging is a foundational control for accountability and incident response.

What Pavois checks

Pavois reads the effective unit state via service('systemd-journald.service') (systemctl is-enabled / is-active). journald is socket-activated and normally static, so Pavois confirms it is actually running rather than merely installed. Checking effective state catches a masked or crashed journald, a condition a file-based check of /etc/systemd/journald.conf would entirely miss while logging is silently broken.

describe service('systemd-journald.service') do
  it { should be_enabled }
  it { should be_running }
end

How to verify it is applied

Run systemctl is-active systemd-journald.service (expect active) and confirm log flow with journalctl --no-pager -n 5 (should return recent entries). systemctl status systemd-journald.service should show Active: active (running).

Inspect & investigate

The daemon's own health is in journalctl -u systemd-journald.service. Overall journal availability and storage are shown by journalctl --disk-usage and journalctl --verify. If the journal is empty or --verify reports corruption, logging integrity is compromised.

Remediation

Pavois's harden plan acts on the service resource named systemd-journald: it runs enable and start so the journal is captured at boot and immediately. It is applied with pavois harden apply. journald is shipped with systemd and normally always present; this control mainly guards against an accidentally masked unit.

Pavois applies this with its own harden engine, the plan below, not a shell script:

actionenable, start
namesystemd-journald.service
resourceservice
pavois harden plan local

where the target is local, a user@host SSH alias, or a container , Docs

Impact & precautions

There is essentially no downside to keeping journald running, it is a core system component. The real risk is the opposite: a missing or masked journald means silent loss of all logging. Precautions: ensure Storage= in /etc/systemd/journald.conf is set appropriately (persistent to survive reboots) and that /var/log/journal has adequate space and rotation (SystemMaxUse=) so the journal cannot exhaust the disk.

Standards mapping

StandardReferenceTypeVersionConfidence
CIS6.1.1.1, 6.2.1.1, 6.2.1.1.1directper OS, see the benchmark tablehigh
NISTSC-24supporting800-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.

Sources & references