How to Safely Clear Ubuntu Logs and Free Up Disk Space

Introduction / Why This Is Needed

System logs in Ubuntu (located in /var/log/) can eventually occupy gigabytes of disk space, especially on servers or workstations with high activity. This can lead to the /var partition filling up and causing system failures.

This guide will show you how to safely clear both classic text logs and the systemd-journald journal. You will learn to distinguish critical logs from obsolete ones, master the essential commands, and understand how to configure automatic rotation to prevent the problem from recurring.

Requirements / Preparation

Before you begin, ensure that:

1. You have terminal access and sudo (administrator) privileges.
2. You are running Ubuntu 22.04+ or a compatible distribution (Debian, Linux Mint).
3. You understand that you must not delete files like auth.log, syslog, or kern.log without understanding the consequences. We will only delete obsolete (archived) entries.

Important: If you are on a server, make sure you have free space to perform the operations (at least 100-200 MB).

Step 1: Assess Current Log Disk Usage

First, find out what exactly is consuming space in /var/log.

# Check the total size of the /var/log directory
sudo du -sh /var/log

# See the top-20 largest files and directories inside /var/log
sudo du -ah /var/log 2>/dev/null | sort -rh | head -n 20

What to look for:

• journal/ — these are the binary logs from systemd-journald. You can check their size separately: sudo journalctl --disk-usage.
• Files with extensions .gz or .1, .2 — these are already compressed, rotated logs. They can be deleted.
• Large files without extensions (e.g., syslog, kern.log) — these are active logs. Do not delete them entirely! You should either archive them via logrotate or clear their contents (see Step 4).

Step 2: Clear the systemd Journal (journalctl)

This is the safest way to manage the system journal. journalctl understands its internal structure.

# Clear logs older than 7 days
sudo journalctl --vacuum-time=7d

# Clear logs, keeping no more than 100MB
sudo journalctl --vacuum-size=100M

# Clear logs, keeping no more than 10 files (segments)
sudo journalctl --vacuum-files=10

Which method to choose?

• --vacuum-time — best if you want to retain logs for the last N days.
• --vacuum-size — a hard limit on space. The system will delete the oldest entries until it falls below the threshold.
• --vacuum-files — limits the number of journal file segments.

💡 Tip: After clearing, check the size: sudo journalctl --disk-usage.

Step 3: Clear Old Compressed Logs in /var/log

Here we will delete archived compressed files (.gz) created by logrotate. They are usually not needed for real-time diagnostics.

# Navigate to the logs directory
cd /var/log

# Find and delete all .gz files older than 30 days (the -mtime +30 parameter)
sudo find . -name "*.gz" -type f -mtime +30 -delete

# Also delete old rotated files without compression (e.g., .1, .2)
sudo find . -name "*.[0-9]" -type f -mtime +30 -delete

Safe alternative (recommended): Instead of -delete, first see what will be deleted:

sudo find . -name "*.gz" -type f -mtime +30 -ls

Make sure the list does not contain any archives you want to keep (e.g., old logs from a specific application).

Step 4: Clear Current Application Logs (Caution!)

Do not delete the files! This can disrupt applications writing to them. Instead, clear their contents if you don't need them for current debugging.

# Clear a file's contents without deleting the file itself (safest method)
sudo truncate -s 0 /var/log/syslog
sudo truncate -s 0 /var/log/kern.log
# ... and other active logs you want to reset

# Or using the cat command (redirect to /dev/null)
sudo cat /dev/null > /var/log/syslog

⚠️ Important: Do not perform this operation on auth.log or faillog on a production server without extreme necessity—they store login and access attempt records.

Step 5: Check and Configure logrotate for the Future

logrotate is the daemon that automatically rotates, compresses, and deletes old logs. Ensure it is running and configured appropriately.

# Check the main logrotate configuration file
cat /etc/logrotate.conf

# View configurations for specific packages in /etc/logrotate.d/
ls -la /etc/logrotate.d/

# Check when logrotate last ran
sudo ls -la /var/lib/logrotate/status

How to tighten the policy? For example, for syslog and kern.log (config in /etc/logrotate.d/rsyslog):

/var/log/syslog
/var/log/kern.log
{
    rotate 7          # Keep 7 archives (weeks)
    daily             # Rotate every day
    compress          # Compress
    delaycompress     # Compress on the next cycle, not immediately
    missingok         # Don't fail if the file is missing
    notifempty        # Don't rotate empty files
    create 640 syslog adm  # Create new file with these permissions
    sharedscripts
    postrotate
        /usr/lib/rsyslog/rsyslog-rotate
    endscript
}

Change the rotate value (e.g., to 4 to keep 4 days) and run sudo logrotate -f /etc/logrotate.conf to force-apply the changes.

Verification

1. For journalctl: sudo journalctl --disk-usage — the size should be significantly reduced.
2. For /var/log: sudo du -sh /var/log — the total size should be smaller.
3. For specific files: ls -lh /var/log/*.gz — the list of archived logs should contain only recent files.
4. Ensure the system is still working: Try running a command that writes to the log (e.g., sudo systemctl status) and check that a new log file is created: ls -lh /var/log/syslog.

Potential Issues

• "Permission denied" when deleting files: Ensure you are using sudo. Some files in /var/log may belong to other users (e.g., root or syslog).
• Space not freed after deleting files: A process (daemon) might hold an open file descriptor on the deleted file. Solution: Restart the relevant service (e.g., sudo systemctl restart rsyslog for classic logs) or sudo systemctl restart systemd-journald for journald. Alternatively, run sudo logrotate -f.
• System stops writing logs after cleanup: You may have accidentally deleted an active log file instead of its contents. Solution: Restart the service that was writing to it (e.g., sudo systemctl restart rsyslog). It will recreate the file.
• Logrotate is not running: Check if the cron daemon is running (it handles the daily logrotate launch): sudo systemctl status cron. Also check configuration files in /etc/logrotate.d/ for syntax errors.

Additional Recommendations

• Monitoring: Add a simple script to cron to monitor space in /var/log and send a notification if it exceeds, for example, 80%.
• Targeted Applications: For logs from specific applications (nginx, mysql, docker), configure their own rotation via logrotate or the software's built-in settings. Configs are usually located in /etc/logrotate.d/.
• systemd Journal: Configure SystemMaxUse, MaxRetentionSec, and MaxFileSec in /etc/systemd/journald.conf for global control over journald. After changes, run sudo systemctl restart systemd-journald.
• Security: If you administer a server, never delete auth.log and secure without taking a copy for incident investigation. Only clean up old archived versions.

By following these steps, you can keep the /var/log directory clean, preventing disk space issues without disrupting system operation.