logrotate: keeping log files from filling your disk

Log files are the most common way a server disk fills up without anyone noticing. Applications log every error, web servers log every request, and if nobody cleans up, those files grow to gigabytes within months. At 100 percent disk usage the database stops writing, sessions are lost and the site starts returning errors. On Linux the standard fix is logrotate, which rotates logs on a schedule, compresses old copies and deletes anything beyond a set count.

Find what is filling the disk

Start by checking overall usage and the largest items under /var/log. Usually one or two files are to blame.

df -h /
sudo du -sh /var/log/* 2>/dev/null | sort -h | tail -10
journalctl --disk-usage

If /var/log is small, check the application directory too. Laravel's storage/logs, WordPress's wp-content/debug.log and custom script logs are often outside the default rotation.

Example: a 4 GB error log on a school site

A private school in Samarkand ran misol.uz on Laravel. One day it stopped saving pupils' grades. For months the app had written the same warning on every request, and laravel.log had reached 4 GB and used up the disk. Emptying the file was a temporary fix; the real fix was correcting the warning in code and adding a logrotate rule. The log never again grew past a few dozen megabytes.

How logrotate works

Global settings live in /etc/logrotate.conf and per-service rules in /etc/logrotate.d/. Most distributions run it once a day from a systemd timer or cron. Each rule says which files it covers, how often to rotate, how many copies to keep and what to do afterwards.

A rule for application logs

Create /etc/logrotate.d/misol. This rule rotates daily, keeps 14 compressed copies and leaves the newest copy uncompressed for a day with delaycompress.

/var/www/misol/storage/logs/*.log {
    daily
    rotate 14
    compress
    delaycompress
    missingok
    notifempty
    copytruncate
}

copytruncate copies the file and then truncates the original, which suits apps that keep the log open and cannot reopen it on a signal. A few lines written between the copy and the truncate may be lost; if the program can reopen its log, create plus postrotate is safer.

Nginx logs and postrotate

Here the old file is renamed, a new one is created with the right permissions and Nginx receives USR1, which makes it reopen its logs without a restart. sharedscripts runs the script once for all files.

/var/log/nginx/*.log {
    daily
    rotate 30
    compress
    delaycompress
    missingok
    notifempty
    create 0640 www-data adm
    sharedscripts
    postrotate
        [ -f /var/run/nginx.pid ] && kill -USR1 $(cat /var/run/nginx.pid)
    endscript
}

Test before trusting

-d shows what would happen without changing anything, -f forces a rotation now.

sudo logrotate -d /etc/logrotate.d/misol
sudo logrotate -f /etc/logrotate.d/misol
ls -lh /var/www/misol/storage/logs/

The systemd journal and deleted-but-open files

If the journal is large, vacuum it once and set a permanent cap.

sudo journalctl --vacuum-size=500M

# /etc/systemd/journald.conf
[Journal]
SystemMaxUse=500M

sudo systemctl restart systemd-journald

Sometimes deleting a log with rm frees nothing, because a process still holds it open. The command below lists such files; restarting the service releases the space. Emptying an active log with truncate -s 0 avoids the problem.

sudo lsof +L1 | grep -i log

Your own logrotate on shared hosting

On shared hosting the provider handles system and web server logs, but your application logs count against your quota. Without root you can still run logrotate as your own user with a private config and state file (-s), scheduled through cron jobs in ISPmanager. Adjust the paths and check the binary location with which logrotate.

# ~/logrotate.conf
/home/user/www/misol.uz/storage/logs/*.log {
    weekly
    rotate 8
    compress
    missingok
    notifempty
    copytruncate
}

# cron: every day at 03:30
30 3 * * * /usr/sbin/logrotate -s $HOME/.logrotate.state $HOME/logrotate.conf

If the command is not available or your quota keeps filling up, sayt.uz support can review your logs and disk usage with you. And always fix the repeating error that makes the log grow, otherwise rotation only hides it.