How to clear journalctl logs and free up disk space

Why does journalctl consume so much disk space on Linux?

Administrators managing servers or workstations running modern Linux distributions frequently encounter a silent problem: the hard drive mysteriously loses storage capacity over time. In most cases, the culprit behind this sudden disk consumption is the centralized system logging service known as systemd-journald. In practice, this background service collects messages from the kernel, applications, and system services, writing everything continuously into compressed binary files inside the /var/log/journal directory. Because these records accumulate indefinitely by default, servers running verbose applications or suffering continuous automated security scans quickly consume dozens of gigabytes solely with historical logs.

Before taking any drastic cleaning measures, it is essential to check the current storage consumption to measure the impact of the intervention. To achieve this, you can use the native journalctl command, which displays an immediate summary of the disk space occupied by the log folders. In practice, this means running a quick terminal instruction that automatically calculates all stored files. If you notice that the accumulated volume is critical enough to threaten system stability, it is also worth exploring other cleanup fronts, such as checking our guide on how to free up disk space on Linux with ncdu to visually map heavy files and directories.

How to check the current size of system logs

To find out exactly how much storage the system logs are consuming on your hard drive, open the terminal and execute the command responsible for querying journal storage usage. This instruction reads the metadata of the binary files and presents the consolidated total value on screen, allowing you to decide whether cleanup is urgent. This verification is mandatory before running any deletion routine, preventing you from wasting time purging logs when the real storage bottleneck lies elsewhere, such as in old package caches covered in our tutorial on how to clear Apt cache on Ubuntu and free disk space.

journalctl --disk-usage

Upon executing this instruction, the terminal will return a single line reporting the total occupied size, which can range from a few megabytes on freshly installed systems to tens or hundreds of gigabytes on neglected production servers. Knowing this exact figure is the first step in planning your retention strategy. If the value is alarming, the next logical step involves applying removal filters to erase excess data without corrupting the log database structure.

Practical procedure to clean logs by size or time

When disk space reaches critical levels, administrators must rely on pruning commands to eliminate older records and recover storage capacity. Systemd provides native, highly efficient tools to delete logs based on time criteria or maximum allowed volume. In practice, you can choose whether to keep only records from the past few weeks or limit the total size that the log folder can occupy. Below is the step-by-step procedure to perform this cleanup safely in the terminal:

1. Open the terminal with administrative privileges (root) to ensure proper write and delete permissions in protected system directories.
2. Execute the cleanup command to retain only log files corresponding to your desired timeframe, such as the last seven days.
3. Execute the complementary size-based pruning command to force the system to discard old files until reaching the established storage cap.

The command to erase records older than a specific time interval uses the --vacuum-time flag, while size-limited cleanup utilizes the --vacuum-size flag. See the practical application of these commands in the blocks below:

sudo journalctl --vacuum-time=7d

sudo journalctl --vacuum-size=500M

In practice, the first command removes all log files generated more than seven days ago, while the second restricts total storage to a maximum of five hundred megabytes, deleting older records until that target is reached. These procedures immediately restore breathing room to the operating system and prevent crashes caused by root partition exhaustion. If your environment runs containers, keep in mind that Docker also tends to accumulate orphaned layers that consume disk space, an issue easily resolved by following the tips in our article on how to clean Docker cache and free up disk space.

How to configure permanent limits in journald.conf

Running manual cleanup commands resolves the immediate emergency, but it does not prevent the problem from returning in subsequent weeks as new logs continue to accumulate. To ensure long-term sustainable operation, you must edit the global configuration file of the journal service, named journald.conf. In practice, this file dictates the permanent rules that the operating system must follow to control log file growth autonomously, without requiring constant human intervention.

To make this definitive change, open the configuration file located at /etc/systemd/journald.conf using a text editor with administrative privileges, such as nano. Inside, you will find several lines commented out with the hash character (#), indicating default factory values. The procedure involves locating the size and time limit directives, uncommenting them, and setting your preferred values. Below is a typical snippet that needs adjustment:

[Journal]
#Storage=auto
#Compress=yes
SystemMaxUse=1G
SystemKeepFree=500M
MaxRetention=1month

In this practical configuration, we define that the journal can occupy a maximum of one gigabyte of disk space (SystemMaxUse), require the system to always keep at least five hundred megabytes free on the partition (SystemKeepFree), and stipulate that no record should be kept for longer than one month (MaxRetention). After saving the file, you must restart the journal service for the new rules to take effect immediately. To do this, execute the systemd-journald restart command in the terminal.

sudo systemctl restart systemd-journald

Final thoughts on log management in Linux

Keeping the operating system clean and maintaining adequate disk space is an essential duty to ensure the stability of any Linux-based infrastructure. The uncontrolled accumulation of logs generated by systemd-journald represents a common trap affecting everything from large enterprise servers to small development boxes. By mastering pruning commands and properly configuring retention limits in the configuration file, you eliminate the risk of sudden outages caused by full partitions.

Adopting a proactive monitoring and cleanup routine prevents unpleasant surprises and ensures hardware always operates within safe performance margins. Combining these log management best practices with periodic cleanup of package caches and containers guarantees a robust, predictable, and highly reliable Linux environment for running any corporate or personal workload.