Why Systemd’s Journal Logs Are Binary (and Why That’s Not as Evil as It Sounds)

 If you’ve ever poked around a modern Linux system and typed ls /var/log/journal, you’ve probably been greeted by a pile of opaque .journal files instead of the familiar plain-text logs you’ve known for decades. Open one in less or cat and you get garbage. Many long-time Unix users react with mild horror: “What happened to the sacred tradition of human-readable text files?”

This post explains the deliberate design decision behind systemd’s journal, the philosophy that drove it, and how it compares to the classic files in /var/log.

The Classic Unix Way: Text Is King

For most of Unix history, system logs lived as simple append-only text files:

• /var/log/messages
• /var/log/syslog
• /var/log/auth.log

You could grep, tail -f, awk, zgrep across rotated files, or even open them in vi when things went wrong. The format was loosely structured at best: a timestamp, a hostname, a program name, and a free-form message. Everything else was either missing or jammed into the text string in ad-hoc ways.

This model is transparent, tool-friendly, and extremely robust when the system is half-broken. It embodies the classic Unix philosophy: plain-text is the universal interface.

Enter the Journal

systemd-journald takes a different approach. It stores log data in a binary, structured, indexed format under /var/log/journal/ (or /run/log/journal/ for volatile storage). The files are not meant to be read directly by humans or classic text tools. This was not an accident or a power grab. The journal was designed from the ground up as a structured event store rather than a diary written for humans.

The Design Goals Behind the Binary Format

The creators wanted several capabilities that pure text struggles with:

1. Rich, reliable metadata
   Every entry can carry dozens of key/value fields: PID, UID, GID, systemd unit, cgroup, executable path, SELinux context, boot ID, priority, and more. Some of these fields are added automatically by the journal itself in a way that is hard for a process to fake. In classic syslog these details are either absent or easy to spoof.
2. True structure and indexing
   Because fields are first-class citizens, the journal can index them. Queries such as “show me all errors from the ssh unit since the last boot” become fast and precise instead of requiring fragile regular expressions over megabytes of text.
3. Support for binary data
   Coredumps, firmware dumps, SCSI sense data, or other non-text payloads can be stored cleanly. Text logs force awkward encoding or simply drop this information.
4. Efficiency and robustness
   The format is primarily append-only, supports inline compression, deduplicates repeated fields, and is designed to survive crashes reasonably well. Important operations scale better than linear scans of text files.
5. Consistency across the whole boot process
   Early-boot and late-shutdown messages are captured more reliably than with traditional syslog setups.

In short, the journal treats logs more like a lightweight database of structured events than like a human-readable notebook.

The Trade-offs (Yes, There Are Real Ones)

The binary format is not free:

• You need journalctl (or another tool that understands the format) to read the data.
• Classic one-liners (grep ERROR /var/log/*) no longer work directly on the journal files.
• Corruption, while handled by rotation and best-effort recovery, can feel more opaque than a damaged text file.
• Some people simply prefer the transparency and universality of plain text.

These complaints are legitimate. Text logs remain excellent for many use cases, especially when you want maximum simplicity or when the system is so broken that only the most basic tools are available.

You Don’t Have to Choose Extremes

Modern distributions usually give you options:

• Keep a traditional syslog daemon (rsyslog, syslog-ng, etc.) running alongside the journal. It can pull data from the journal and write classic text files.
• Use journalctl with friendly output formats (-o short, -o json, -o export, etc.).
• Configure Storage=volatile or Storage=none in journald.conf if you want minimal persistence.
• Export or forward the journal data to centralized logging systems that prefer structured formats anyway.

In practice, many administrators end up using both: the journal for rich, queryable local data and text files (or a remote collector) for the classic workflow and long-term archival.

Philosophy in a Nutshell

The traditional /var/log files prioritize human readability and tool universality.
The systemd journal prioritizes structure, metadata richness, query performance, and reliability for a modern, service-oriented system.

Neither approach is pure evil or pure good. They optimize for different priorities. The journal simply decided that, for the volume and complexity of data a contemporary Linux system generates, treating logs as structured records is more useful than treating them as free-form prose.

Whether you love it, hate it, or just live with it, understanding the “why” makes the binary files in /var/log/journal a lot less mysterious.