$ Linux One Liners
Back to problems

problem hub

Read-only first

Journal logs too large on Linux

Measure systemd journal usage and retention before vacuuming logs or deleting journal directories.

Safest first command

journalctl --disk-usage

Before you run this

Expected output: A human-readable total for archived and active journal files.

When not to use it: Do not vacuum or delete logs before capturing incident evidence, retention requirements, and whether the logs are still needed for security or compliance review.

Expected output example

Archived and active journals take up 3.4G in the file system.

How to read the result

The number is total journal storage, not necessarily reclaimable space. Decide whether the pressure is journal-specific or part of broader /var disk pressure.

What to check next

Journal usage is large and /var is full

Means: Journal retention may be one contributor to disk pressure.

Next step: Compare journal size with /var and other hot directories before vacuuming.

Find Which Folder Is Filling the Disk

Recent incident is still under investigation

Means: Vacuuming may remove evidence needed for diagnosis.

Next step: Export or capture relevant logs before retention changes.

Read Current-Boot Logs for One Service

Journal usage keeps growing quickly

Means: A noisy service may be flooding logs.

Next step: Find warning/error-heavy units before changing retention.

Group Journal Errors by Unit

Journal log decision tree

Start by measuring journal usage, then compare it to the full filesystem and current incident timeline. systemd journal vacuum commands do not provide a reliable dry-run preview on all systems, so capture evidence first.

  1. journalctl --disk-usage
  2. du -sh /var/log/journal 2>/dev/null
  3. du -xhd1 /var/log 2>/dev/null | sort -h

Cleanup only after evidence is captured

This deletes journal data. Capture incident evidence, confirm retention needs, and compare journal usage with the rest of /var before running a vacuum command. If your journalctl version does not support a dry-run style preview, treat vacuuming as a real deletion.

  1. journalctl --disk-usage
  2. journalctl -p err..alert --since "2 hours ago" --no-pager
  3. journalctl --vacuum-time=7d

Bad fixes to avoid

Do not delete /var/log/journal manually. Do not vacuum logs before capturing incident evidence. Do not use journal cleanup as a substitute for fixing a service that is flooding logs.

Common causes

  • Verbose failing service
  • Long retention with persistent journal
  • Small /var filesystem
  • Container or host log burst
  • Old incidents never vacuumed

What not to change yet

  • Do not delete journal directories manually.
  • Do not vacuum before collecting current incident logs.
  • Do not ignore the service producing the log volume.

Stop and escalate if

  • The next step could interrupt users, remove data, or lock out access.
  • The output includes secrets, customer data, or private infrastructure details.
  • You cannot explain the blast radius of the repair command.

platform notes

Distro and service notes

systemd

Vacuuming deletes journal data; retention settings belong in journald configuration.

Storage

Use the disk-full hub if /var has multiple large contributors.

supporting commands

Command path

Guides and drills