Running Out of Disk Space on Linux? Check Your Logs!

Summary

• Linux system logs can take up a significant amount of disk space.
• Your system will normally compress older log files to save disk space.
• You can use the journalctl or tail -f command to view logs and identify problematic processes.

While Linux systems have a reputation for being svelte, you may find that you’re suddenly running low on disk space. Why has this happened? The biggest clue, and possibly the biggest culprit, will be found in your Linux system logs.

Why Are Logs Taking Up So Much Disk Space?

Logs are an important part of managing your Linux system. You can see what’s going on with your machine, and you can also troubleshoot issues that arise. Linux logging daemons are similar to Event Viewer on Windows. The logs normally don’t take up much space. This is because most distros will automatically manage how much space they take up on your disk.

Linux logs have historically been plain text files, but with many major distros moving to systemd, they’re binary files that are managed by journald, a systemd service. Alternatively, your distro will either use rsyslog or syslog-ng.

Because old logs aren’t relevant and large archives can take up space, your system will usually “rotate” them—archive, compress, and ultimately delete them—to save disk space for the stuff you actually want.

While you might not think that logs would take up a lot of space, a malfunctioning process can fill up your logs faster than the system can rotate them.

If you check your disk space and find yourself suddenly running low, and you know you haven’t downloaded any large files recently, the cause may be a problem with your Linux system logs. You’re going to have to find out what’s filling up your system logs and fix it.

You can check how much disk space you’re using with the du -h command:

du -h /var/log

You’ll see a list of each subdirectory, together with the total amount of space it takes up:

Finding Your Logs

If you use a modern Linux distro with systemd, you’ll use the journalctl program to view your logs; journald typically stores logs in the /var/log/journal or /run/log/journal directories, depending on the distro.

To view the logs, type the journald command at the shell prompt. There are other useful command line options. To view the boot messages, use the -b option:

journalctl -b

You can view your system’s log messages in real time with the -f option.

If your distro doesn’t use systemd, you’ll find the logs in the /var/log directory. Even with systemd, some programs still store their logs in this directory. These are ordinary text files that you can examine with a utility like a pager, such as less.

For example, to read the system log:

less /var/log/syslog

You'll see the full contents of the log file which may contain thousands of lines:

You can also monitor it in real time with the tail command’s -f option:

tail -f /var/log/syslog

How Linux Rotates Log Files

In the /var/log directory, you may notice files with names ending in “log.N.gz,” where N is a number. This is the result of the system rotating older logs. Most distros have a utility that will do this automatically, called “logrotate.” logrotate is typically set up to run as a cron job or a systemd timer.

By default, most distros will run logrotate daily. logrotate compresses older logs using gzip, as evidenced by the “.gz” file extensions. It uses a threshold, like age or file size, to do this, and another threshold to eventually delete old log files.

The default options for logrotate are sufficient for most desktop users. You can tweak logrorate’s behavior by editing the /etc/logrotate.conf file as superuser, as well as editing your system’s cron or systemd timer files, but these operations are really only relevant to server administrators.

You’re better off fixing what’s filling up your logs than tweaking configuration files to save disk space. If you absolutely must change the configuration, you can read the logrotate manual page.

Which Logs Are Safe to Delete?

If all else fails and you’re desperate to free up disk space, you can manually delete the archived log files ending in “.gz” before logrotate does. You can use rm, but you’ll need to run it as superuser since these files belong to the system:

sudo rm /var/syslog/syslog.*gz

This command will delete all files containing “syslog.” and ending with “gz.”

Always be very careful when running commands via sudo, especially destructive commands like rm!

You shouldn’t normally delete files in system directories without fully understanding the implications, but archived logs won’t cause any problems if they’re missing. If you do have a problem, you might need to refer to older logs, though.

How to Fix What’s Filling Up Your Logs

The best way to find out what’s filling up your logs is to follow the logs with the journalctl or tail -f options. Your best bet is repeating error messages.

You’ll have to deal with the offending process to save disk space. If you don’t know what’s causing the error, you can search the web or ask for help on your distro’s support channels. When you’ve finally fixed it, you can delete the older logs safely. You should have much more disk space now.