journald and journalctl: Logging the systemd Way

With systemd, logs become easier to query consistently because journald stores service and kernel events in a unified journal. journalctl gives you fast filters by unit, boot, time range, and severity.

Table of Contents

This post focuses on practical query patterns and retention controls for daily operations.

Journald Basics

High-Value Filters

Retention and Operations

Series Navigation

How journald differs from traditional syslog

Traditional Linux logging often centered on flat files under /var/log. journald adds structured metadata and consistent unit linkage, so you can ask for logs by service identity rather than parsing broad files.

Core differences:

  • Logs are indexed by fields such as unit, PID, UID, and boot ID
  • Kernel and service logs can be queried through one interface
  • Time range and priority filters are first-class query options
  • Output can be viewed in short, verbose, JSON, or exported formats

Read recent logs quickly

Start with recent entries to establish timeline and context.

journalctl -n 50
journalctl --no-pager -n 100

Use --no-pager in automation or when piping output to other tools.

Follow logs live

For active debugging, follow logs in near real time.

journalctl -f
journalctl -u nginx.service -f

This is often the fastest way to verify whether config reloads and restarts behave as expected.

Filter by unit, boot, time, and priority

The most useful filters can be combined:

journalctl -u sshd.service
journalctl -u nginx.service -b
journalctl --since "2026-05-17 08:45:00" --until "2026-05-17 09:05:00"
journalctl -p warning..alert
journalctl -u docker.service -b -p err..alert

Common use cases:

  • -u scopes to one service unit
  • -b limits to current boot unless a boot offset is provided
  • --since and --until constrain incident windows
  • -p narrows output to significant severities

Inspect kernel messages

Kernel events are available directly without switching tools.

journalctl -k
journalctl -k -b -p warning

This is useful for hardware errors, driver issues, and boot-time kernel warnings.

Use metadata filters

You can filter on journal fields when you need precision beyond unit names.

journalctl _SYSTEMD_UNIT=sshd.service
journalctl _PID=1
journalctl _UID=0

Metadata-driven filtering helps when multiple services emit similar message text.

Configure persistent journals

On some systems, journal data is volatile unless persistent storage is enabled.

/etc/systemd/journald.conf example:

[Journal]
Storage=persistent
SystemMaxUse=1G
SystemKeepFree=500M
MaxRetentionSec=1month

After changes:

sudo systemctl restart systemd-journald

Choose limits that fit disk capacity and compliance requirements.

Forwarding and mixed environments

If your environment still relies on rsyslog or another collector, journald can forward entries.

[Journal]
ForwardToSyslog=yes

Use one authoritative retention strategy to avoid confusion between duplicated pipelines.

Troubleshooting patterns

A reliable log-first workflow:

  • Check service state with systemctl status
  • Pull recent service logs with journalctl -u <unit> -b -n 100
  • Expand to severity filters when noise is high
  • Correlate with kernel events via journalctl -k -b

Series navigation

Now that logging and observability are covered, the next post moves into custom unit authoring with timers and socket activation.

Next in this series

Next, we build custom units and timer workflows so you can replace many cron and wrapper-script patterns.

Authoring systemd Units: Custom Services, Timers, and Socket Activation