Why Is Disk Space Not Freed After Deleting Log Files?

Introduction: Understanding Disk Space Issues in Linux

When you delete a large log file in Linux using the rm command, you might expect the disk space to be immediately available. However, many users notice that, after running the command, the disk space remains unchanged when checked with df -h. This article explores why this issue occurs, especially in an environment like Ubuntu 22.04 with an ext4 filesystem, and how to address it without restarting the service.

Why Does Linux Behave This Way?

The primary reason disk space is not immediately freed after deleting a log file is due to how file descriptors work in Linux. When a service opens a log file for writing, it maintains a file descriptor for that file. Thus, even if you delete the file from the filesystem using the rm command, the file's data remains on the disk as long as the service is running and holds that file descriptor. This is a behavior specific to Linux and Unix-like systems, allowing processes to continue working with files they have opened, even if those files are deleted.

In your case, the service continues to write logs to the /var/log/myapp.log file, which means the space used by that file won’t be released until the service is stopped or if the log file is rotated or replaced properly. It’s a common scenario when managing log files for applications running as systemd services.

How to Free Disk Space Without Restarting the Service?

To reclaim the disk space used by the deleted log file without restarting the service, you can use the following methods:

1. Log Rotation

Implementing log rotation is a standard practice that can help manage log file sizes and free up space efficiently. The logrotate utility in Linux is designed to automate the process of rotating, compressing, and removing old logs. You can set it up for your application’s log like this:

sudo nano /etc/logrotate.d/myapp

Then, add the following configuration:

/var/log/myapp.log {

    daily

    missingok

    rotate 7

    compress

    delaycompress

    notifempty

    create 0640 root adm

    sharedscripts

    postrotate

        systemctl reload myapp.service

    endscript

}

This configuration will rotate the log daily, keep the last 7 logs, and reload the service after rotation, ensuring that space is freed as soon as old logs are deleted.

2. Truncate the Log File

If you want to free up disk space immediately and you don’t need the content of the log file, you can truncate it. The truncate command is perfect for this:

sudo truncate -s 0 /var/log/myapp.log

This command will set the size of the log file to 0 bytes, effectively clearing it without deleting it, which allows the service to continue writing to the same log file and releases space on the disk.

Conclusion

Understanding how file descriptors work in Linux helps clarify why deleting log files doesn’t immediately free up disk space. Instead of restarting your service, options like log rotation and truncation offer effective solutions to manage log files and reclaim disk space. Regular log management practices, including the use of logrotate, not only keep your disk space in check but also ensure your logging system runs smoothly without interruptions.

Frequently Asked Questions

What happens to deleted files in Linux?

When you delete a file in Linux, the space is freed only when no processes are using the file descriptor associated with that file. The data is still present until those processes close the file.

Can I recover deleted log files?

Recovering deleted log files is often very difficult, especially if the space has been reused. However, specialized recovery tools may be able to retrieve some data if it hasn't been overwritten.

Is log rotation necessary?

Yes, log rotation is crucial for maintaining system performance and preventing issues related to disk space consumption. It helps automate the management of log files.