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 October 13, 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. Correlating timestamps across multiple machines only works if their clocks agree in the first place - see Time Synchronization.

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-tmpfiles --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 on many systemd systems rsyslog runs alongside journald specifically to mirror journal entries out into the traditional files other tooling expects. It isn't universal any more, though: fresh Debian 12+ and Fedora installs don't include rsyslog, so the syslog/messages/auth.log/kern.log files below only exist there if you install it (sudo apt install rsyslog). Everything they would contain is in the journal regardless.

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
journalctl _COMM=sshd | grep "Failed password"   # same check, works without rsyslog

Searching for failed SSH passwords 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.