Logs and journald

Where Linux logs actually live and how to read them - journald's structured, queryable log on systemd systems, alongside the traditional plain-text files under /var/log that many tools still expect.

Administration Updated August 28, 2026

  • administration
  • logging
  • systemd

Every service managed by systemd has its output captured automatically by journald - no per-application log file configuration required, which is a meaningful change from the traditional model of every daemon writing its own file under /var/log.

Reading logs with journalctl

journalctl                    # everything, oldest first
journalctl -u nginx           # just one systemd unit
journalctl -f                 # follow, like `tail -f`
journalctl -b                 # just since the current boot
journalctl -b -1              # the *previous* boot (useful after a crash)

Filter by time or severity:

journalctl --since "1 hour ago"
journalctl --since "2026-08-27" --until "2026-08-28"
journalctl -p err             # error priority and above only

Aug 27 09:14:02 web01 nginx[1050]: nginx: [emerg] bind() to 0.0.0.0:443 failed
Aug 27 09:14:02 web01 systemd[1]: nginx.service: Failed with result 'exit-code'.

Combine a unit and a time window when chasing something specific - e.g. journalctl -u nginx --since "10 min ago" - rather than scrolling unfiltered output.

See systemd and Services for what a unit actually is, and Boot Process for using journalctl -b to diagnose a slow or failed boot specifically.

Where journald actually stores data

By default on many distributions, the journal is volatile - kept only in /run/log/journal (tmpfs, cleared on reboot) unless a persistent directory exists:

sudo mkdir -p /var/log/journal
sudo systemd-tempfiles --create --prefix /var/log/journal
sudo systemctl restart systemd-journald

Once /var/log/journal exists, journald switches to writing there instead, surviving reboots. Check current disk usage and prune old entries if needed:

journalctl --disk-usage
sudo journalctl --vacuum-time=2weeks

Traditional /var/log files haven't disappeared

Many tools, and non-systemd software, still write plain-text logs directly, and even on systemd systems rsyslog commonly runs alongside journald specifically to mirror journal entries out into the traditional files other tooling expects:

File Typical contents
/var/log/syslog (Debian/Ubuntu) or /var/log/messages (RHEL/Fedora) General system messages
/var/log/auth.log (Debian/Ubuntu) or /var/log/secure (RHEL/Fedora) Authentication events - logins, sudo usage
/var/log/kern.log Kernel messages
/var/log/dpkg.log / /var/log/dnf.log Package install/upgrade history

See The Filesystem Hierarchy for why /var specifically is where this kind of runtime data lives.

tail -f /var/log/auth.log
grep "Failed password" /var/log/auth.log

That last command is a standard first check when investigating suspicious login activity - see Hardening Basics, which covers fail2ban, a tool that watches exactly this kind of log entry automatically.

Log rotation

Plain-text logs would grow unbounded without logrotate, which runs daily (via cron or a systemd timer) and compresses, renames, and eventually deletes old log files based on rules in /etc/logrotate.d/. journald handles its own size limits and rotation internally via --vacuum-* settings and SystemMaxUse= in /etc/systemd/journald.conf, so it doesn't rely on logrotate at all.