Systemd Journald vs Syslog in Modern Debian

Modern Debian releases utilize systemd-journald as the core mechanism for capturing system logs, significantly changing how logging operates compared to legacy Unix environments. This article covers how Debian uses journald as its primary collector, how it forwards events to traditional syslog daemons like rsyslog, the shift toward running journald as a standalone logging solution, and the specific use cases where traditional syslog services remain necessary.

The Evolution of Logging in Debian

Historically, Debian relied on traditional syslog daemons—most recently rsyslog—to manage system events. In this legacy model, the kernel, background services, and user applications wrote text-based messages directly to the /dev/log socket, which rsyslog formatted and sorted into text files inside /var/log/ (such as syslog, auth.log, and messages).

With the adoption of systemd, systemd-journald became the low-level capture mechanism for all log events. Starting in Debian 12 (Bookworm), the standard installation no longer installs rsyslog by default. Instead, Debian relies entirely on systemd-journald for capturing, storing, and querying logs, marking a decisive shift from hybrid logging to a pure journald implementation.

How systemd-journald Captures Logs

systemd-journald acts as an early-boot, centralized logging daemon that collects data from multiple sources across the operating system:

  • Kernel logs: Captured directly from /dev/kmsg.
  • System services: Captured directly via standard output (stdout) and standard error (stderr), eliminating the need for applications to explicitly implement syslog APIs.
  • Syslog socket: Managed via /dev/log, allowing legacy applications that write to the standard syslog socket to continue working seamlessly.
  • Audit records: Gathered from the Linux Audit framework.

Logs are indexed and stored in structured, binary-formatted journal files. By default, these are held either in memory at /run/log/journal/ (volatile storage, cleared upon reboot) or saved to disk at /var/log/journal/ (persistent storage).

Interaction Between journald and Traditional Syslog Daemons

When an administrator installs a traditional daemon like rsyslog or syslog-ng on a modern Debian system, journald does not get disabled. Instead, the two systems operate concurrently in a coordinated pipeline:

  1. Ownership of /dev/log: systemd replaces the traditional /dev/log socket with a symlink pointing to /run/systemd/journal/dev-log. journald listens on this socket, ensuring it intercepts all standard syslog API calls first.
  2. Forwarding Events: Once journald processes and structures a log message, it passes the data down to the secondary daemon using one of two methods:
    • ForwardToSyslog: When configured with ForwardToSyslog=yes in /etc/systemd/journald.conf, journald outputs messages to /run/systemd/journal/syslog, where legacy daemons read them.
    • Direct Journal Reading: Modern versions of rsyslog in Debian typically use the imjournal input module or socket-based listening (imuxsock) to pull structured metadata directly from the systemd journal.
  3. File Generation: The secondary daemon processes the forwarded messages, applies legacy filter rules, and writes plain-text files into /var/log/.

In this hybrid state, journald acts as the single ingestion engine, while rsyslog functions as a downstream consumer.

Replacing Syslog Entirely with journald

For most standalone Debian deployments, running an additional syslog daemon is redundant. Administrators can maintain a fully featured, syslog-free environment by configuring journald for persistence and using native tools:

  • Persistent Storage: In /etc/systemd/journald.conf, setting Storage=persistent instructs journald to create and maintain /var/log/journal/, preserving logs across system reboots.
  • Log Retention: Disk usage is controlled directly through parameters like SystemMaxUse and MaxRetentionSec, eliminating the need for external tools like logrotate for system services.
  • Querying Logs: The journalctl utility replaces traditional file inspection tools (grep, tail, less). It enables targeted filtering by systemd unit (journalctl -u nginx), boot session (journalctl -b), severity, or precise time windows (--since, --until).

When Traditional Syslog Daemons Are Still Required

Despite journald being the default in modern Debian, traditional syslog daemons are still installed for specialized architectures:

  • Centralized Log Aggregation: While systemd-journal-remote exists, rsyslog and syslog-ng provide mature protocols (RFC 5424), flexible network buffering, and high-performance routing for sending logs to central SIEMs or remote log servers.
  • Plain-Text File Requirements: Legacy log analysis scripts, intrusion detection systems (such as older Fail2ban configurations), or auditing pipelines that require raw, uncompressed text files in /var/log/.
  • Complex Filtering and Routing: Dedicated syslog engines support advanced parsing, message rewriting, and dynamic database insertion that exceed the native capabilities of systemd-journald.