journalctl and logrotate: How to Read and Manage Linux Logs

Two logging systems in Linux

On modern distributions logs live in two places:

• systemd journal: a binary journal collected by journald, with service output, kernel messages and system events. You read it with journalctl.
• Text files in /var/log: classic logs written by rsyslog, Nginx, databases and many applications. Their size is controlled by logrotate.

You need both: the journal answers "what happened", logrotate makes sure logs do not eat the disk.

journalctl: filter by unit

journalctl -u nginx              # all entries for a service
journalctl -u nginx -f           # follow in real time
journalctl -u nginx -n 100       # last 100 lines
journalctl -u app -u worker      # several services at once
journalctl -b                    # since current boot
journalctl -b -1                 # previous boot
journalctl -k                    # kernel messages only

-b -1 is handy after an unexpected reboot: it shows what happened right before it (if the journal is stored on disk, see below).

Filter by time and priority

journalctl --since "2026-10-01 09:00" --until "2026-10-01 10:00"
journalctl -u app --since "1 hour ago"
journalctl -u app --since today -p err

-p keeps entries of the given level and more severe ones. Levels by increasing severity: debug, info, notice, warning, err, crit, alert, emerg. So -p warning shows warnings and all errors.

Other useful options:

• -o json-pretty or -o cat: a different output format;
• --no-pager: plain output without a pager, handy in scripts;
• -g "timeout": search message text (in reasonably recent systemd versions).

Limiting journal size

Check how much space it takes:

journalctl --disk-usage

Set a permanent limit in /etc/systemd/journald.conf (or a drop-in file in journald.conf.d/):

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

Then run sudo systemctl restart systemd-journald. Storage=persistent keeps the journal on disk across reboots; without it, some distributions keep it in memory only.

One-off cleanup of old entries:

sudo journalctl --vacuum-size=300M
sudo journalctl --vacuum-time=14d

Where classic logs live

To see what takes space: sudo du -sh /var/log/* | sort -h.

logrotate: rotation rules

logrotate usually runs once a day (via cron or a systemd timer) and processes rules from /etc/logrotate.conf and /etc/logrotate.d/. An example for application logs:

/var/log/myapp/*.log {
    daily
    rotate 14
    maxsize 100M
    missingok
    notifempty
    compress
    delaycompress
    create 0640 myapp myapp
    sharedscripts
    postrotate
        systemctl reload myapp > /dev/null 2>&1 || true
    endscript
}

What matters here:

• daily / rotate 14: rotate daily and keep 14 archives.
• maxsize: rotate early if the file grows. It only triggers when logrotate runs, so for very fast growth run it more often.
• compress / delaycompress: compress archives but leave the newest one uncompressed in case the process still writes to it.
• postrotate: tell the app to reopen its log file. Otherwise the process keeps writing to the renamed file.
• copytruncate: an alternative for apps that cannot reopen files. A few lines may be lost at the moment of copying.

Testing rules

sudo logrotate -d /etc/logrotate.d/myapp   # dry run, changes nothing
sudo logrotate -f /etc/logrotate.d/myapp   # force rotation

Common mistakes: a rule for a path with no files and no missingok; a forgotten postrotate; wrong permissions in create that stop the app from writing to the new file.

Keeping the disk from filling up

1. A journal limit in journald.conf.
2. A logrotate rule for every file your application writes.
3. Log rotation for Docker containers in the logging driver settings.
4. Disk space monitoring that alerts early, not when the disk is already full.