Linux journal cleanup should not mean discarding the evidence you need. A journal full of yesterday’s repeated errors can occupy space you wanted for today’s work. Yet deleting logs indiscriminately also deletes the evidence that explains why they grew. A better approach is to measure the systemd journal, preserve the relevant messages, remove only older archives and give future growth a sensible boundary. This guide applies to Linux installations that actually use systemd-journald.
Measure before choosing Linux journal cleanup
Open a terminal and run journalctl --disk-usage. This reports the disk space occupied by accessible journal files. On a personal machine, you may need sudo journalctl --disk-usage to see the system journal. Use administrative access only on a machine you own or are authorised to maintain. A work server’s logs may have retention requirements that outweigh a quick storage saving.
Compare that figure with df -h, which shows filesystem usage. If the journal occupies a modest amount while a large video folder fills your home directory, vacuuming logs is the wrong repair. Follow the broader Linux disk-cleanup guide instead of deleting unrelated system files.
Write down the initial size. A before-and-after record prevents a common mistake: assuming that a cleanup worked because the command printed something. It also helps you spot unusually fast regrowth later, which points toward a noisy service rather than insufficient disk capacity.
Save the incident before discarding its history
Look at a bounded period with sudo journalctl --since "1 hour ago" --no-pager. If you already know the affected service, narrow the query with -u and its real unit name. Do not copy a service name from someone else’s machine and assume it exists locally. The upstream journalctl manual documents these filters and the cleanup options.
Save a useful excerpt before removing archives. For example, redirect the relevant query to a new text file in a private directory you control. Check the destination first so you do not overwrite an existing note. Logs can contain usernames, local paths and application details; review and redact an excerpt before attaching it to a public support request.
Repeated connection failures, crash loops or authentication messages deserve investigation. A smaller journal does not fix whichever process produced them. If one service writes the same failure every few seconds, note its name and the first occurrence before you shorten the available history.
Vacuum archives without removing log directories
On a personal computer, sudo journalctl --vacuum-size=500M is an example of asking journalctl to remove older archived files until those archives fall below the chosen size. Five hundred megabytes is an example budget, not a universal recommendation. Decide how much history matters on your machine before copying the value.
The distinction between archived and active files explains an apparent failure: the final disk-usage reading can remain above the requested archive limit. The active journal is not removed by vacuuming. When you deliberately want current files rotated first, journalctl supports combining rotation and vacuuming: sudo journalctl --rotate --vacuum-size=500M. This discards historical evidence; save what you need beforehand.
Do not substitute a recursive delete command targeting /var/log. That directory can contain logs managed by other tools, with different permissions and rotation rules. Nor should you delete application databases or package metadata to make the terminal’s free-space number look better.
Set a continuing budget and watch for regrowth
For persistent journals, systemd documents SystemMaxUse= in its journald configuration reference. A drop-in under /etc/systemd/journald.conf.d/ can keep your local choice separate from the packaged configuration. An example file contains a [Journal] section and SystemMaxUse=500M. Runtime journals use different controls, so read the storage-mode explanation before editing.
Keep a copy of any existing local configuration, edit through an authorised administrator account and reload the service configuration as directed by your distribution. Do not change logging on production systems without the owner’s retention policy and a maintenance procedure. A cap should preserve an appropriate troubleshooting window rather than merely force the smallest possible total.
Recheck disk usage after cleanup and again after normal use. If it grows rapidly, return to the service errors instead of scheduling repeated deletion. For a revived home computer, our Linux Mint setup guide provides wider context. Journal housekeeping belongs alongside healthy applications and backups, not in place of them.