How to Use logrotate in Linux: Prevent Disk-Full Disasters with Automated Log Management

It’s 2 AM. Your monitoring alerts are screaming. The database won’t start, the web server is throwing 500 errors, and SSH feels sluggish. You check the disk and there it is: 100% full. The culprit? A single log file that ballooned to 40 GB while you slept. If you’ve ever lived this nightmare, you already know why you need to learn how to use logrotate in Linux.

I’ve been there. Years ago, back when I was still cutting my teeth as a junior sysadmin, I woke up to exactly this scenario on a production web server. An application was dumping verbose debug output into a single log file with no rotation policy. That file ate the entire /var/log partition overnight. It took me two hours of panicked cleanup to get services back online. That morning, I became a logrotate evangelist. I haven’t had a disk-full log disaster since.

This guide walks you through everything: what logrotate does, how to configure it, real-world examples for Nginx, Apache, and database servers, plus the debugging tricks I use every week. Whether you’re managing a homelab or a fleet of production servers, automated log management will save you from those 2 AM wake-up calls.

What Is logrotate and Why You Need It

The Log Management Problem Every Sysadmin Faces

Every Linux service generates logs. Your web server, your database, your custom applications, even the kernel itself (you can inspect kernel logs with dmesg for hardware-level events). Left unchecked, these files grow without limit.

The math is simple but brutal. A moderately busy Nginx server might write 500 MB of access logs per day. In a month, that’s 15 GB from one service. Multiply across a dozen applications and you’re staring down a disk-full troubleshooting guide instead of your morning coffee. Understanding log rotation fundamentals is essential for any system administrator.

Get a VPS from as low as $11/year! WOW!

How logrotate Solves the Disk Space Crisis

Logrotate automates three critical tasks:

• Rotation: Renames the current log file and creates a fresh one
• Compression: Compresses old logs with gzip, saving 80-90% disk space
• Deletion: Removes logs older than your retention policy

The best part? It’s already installed on most Linux distributions. It runs automatically through cron jobs, typically once a day. You configure it, and it quietly handles everything in the background. If you’re also using systemd’s journal, note that the journalctl command handles its own log rotation separately.

Understanding logrotate Configuration

Before diving into directives, let’s map out where logrotate keeps its files. I always tell people to think of it as three layers. The official logrotate man page covers every detail, but here’s the practical overview.

Main Configuration File: /etc/logrotate.conf

This is your global defaults file. Settings here apply to every log file unless overridden by a more specific config. A typical default looks like this:

# /etc/logrotate.conf
weekly
rotate 4
create
dateext
compress
include /etc/logrotate.d

That last line is the key. It tells logrotate to pull in all the files from the /etc/logrotate.d/ directory.

Application-Specific Configs: /etc/logrotate.d/

Each application gets its own config file in this directory. When you install Nginx, Apache, or MySQL through your package manager, they typically drop a rotation config here automatically. You’ll also create custom configs here for your own applications. For RHEL-based systems, Red Hat’s logrotate setup guide covers distribution-specific details.

State File: /var/lib/logrotate.status

This file tracks when each log was last rotated. Logrotate checks it every run to decide whether a file is due for rotation. If this file gets corrupted (and it does happen), rotation can silently stop working. We’ll cover how to fix that in the troubleshooting section.

Essential logrotate Configuration Directives

Here are the directives you’ll use in 90% of your configurations. I’m grouping them by function so you can find what you need fast.

Rotation Frequency (daily, weekly, monthly)

These are straightforward. Pick one based on how fast your logs grow:

• daily: Rotate every day (high-traffic web servers)
• weekly: Rotate once a week (most common default)
• monthly: Rotate once a month (low-volume logs)

Retention Policy (rotate, maxage)

The rotate directive controls how many old log files to keep. rotate 7 with daily gives you one week of history. maxage deletes files older than a set number of days regardless of the rotation count.

Compression Options (compress, delaycompress)

Always enable compress. Text logs compress incredibly well. A 500 MB access log often shrinks to under 50 MB with gzip. Use delaycompress alongside it. This waits one rotation cycle before compressing, which gives applications time to finish writing to the old file. You can also explore other compression options or the tar command for archiving rotated logs.

File Creation (create, copytruncate)

This is where many people get tripped up. You have two strategies:

Scripts (postrotate, prerotate)

These run commands before or after rotation. The most common use: reloading a service so it starts writing to the new log file. You’ll use systemctl reload commands here almost every time.

postrotate
    systemctl reload nginx > /dev/null 2>&1 || true
endscript

Practical logrotate Configuration Examples

Theory is great, but let’s look at configs you can actually drop into production. These are pulled from my own servers with minor adjustments.

Basic Custom Application Log Rotation

Here’s what I use for a Python Flask application that logs to a custom file:

/var/log/myapp/*.log {
    daily
    rotate 14
    compress
    delaycompress
    missingok
    notifempty
    create 0640 www-data www-data
    sharedscripts
    postrotate
        systemctl reload myapp > /dev/null 2>&1 || true
    endscript
}

The missingok directive prevents errors if the log file doesn’t exist yet. notifempty skips rotation for empty files. sharedscripts ensures the postrotate command runs once, not once per matched file.

Nginx Access and Error Logs

If you’ve followed our guide on Nginx setup, your access and error logs live in /var/log/nginx/. Here’s a solid rotation config:

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

Nginx responds to the USR1 signal by reopening its log files. This is cleaner than a full reload.

Apache Web Server Logs

/var/log/apache2/*.log {
    weekly
    rotate 12
    compress
    delaycompress
    missingok
    notifempty
    create 0640 root adm
    sharedscripts
    postrotate
        if systemctl is-active apache2 > /dev/null 2>&1; then
            systemctl reload apache2 > /dev/null 2>&1
        fi
    endscript
}

Database Logs (MySQL/PostgreSQL)

Database logs are tricky. You can’t just rename the file and send a signal like you do with web servers. That’s why copytruncate is your friend here:

/var/log/mysql/*.log {
    daily
    rotate 7
    compress
    delaycompress
    missingok
    notifempty
    copytruncate
}

No postrotate needed. The original file stays open, and the database keeps writing to it without interruption.

Size-Based Rotation with maxsize

Sometimes time-based rotation isn’t enough. I once had an application that would dump 2 GB of logs in a single hour during peak traffic. Here’s how you handle that:

/var/log/chatty-app/*.log {
    daily
    maxsize 500M
    rotate 10
    compress
    delaycompress
    missingok
    notifempty
    copytruncate
}

The maxsize 500M directive triggers rotation whenever the file exceeds 500 MB, even if the daily schedule hasn’t kicked in yet. This is the safety net that prevents surprise disk-full events.

Testing and Debugging logrotate

Never push a logrotate config to production without testing it first. I learned this the hard way after a bad config silently broke rotation on three servers for two weeks.

Dry Run Mode with -d Flag

The -d flag simulates rotation without actually doing anything. It shows you exactly what logrotate would do:

sudo logrotate -d /etc/logrotate.d/myapp

Read the output carefully. It tells you which files match, what actions it would take, and whether any errors exist in your config.

Force Rotation with -f Flag

When you need rotation to happen right now, regardless of schedule or state file:

sudo logrotate -f /etc/logrotate.d/myapp

This is useful after deploying a new config or recovering from a disk-full situation. You can also add -v for verbose output to see every step.

Checking the State File

If logs aren’t rotating when they should, check the state file first:

cat /var/lib/logrotate/status

Each line shows a log file path and the date of its last rotation. If the dates look wrong or the file is garbled, you’ve found your problem.

Common Errors and How to Fix Them

Common logrotate Problems and Solutions

After years of managing Linux servers, I’ve seen every logrotate failure mode. Here are the ones that come up most often.

Logs Not Rotating (Permission Issues)

The number one cause of silent rotation failure: permission errors. Logrotate runs as root via cron, but it still needs correct permissions on log directories and config files.

# Fix common permission issues
sudo chmod 755 /var/log/myapp
sudo chown root:root /etc/logrotate.d/myapp
sudo chmod 644 /etc/logrotate.d/myapp

Config files in /etc/logrotate.d/ must be owned by root and not writable by group or others. If they are, logrotate skips them silently.

Disk Full Before Rotation Runs

Ironic, right? Logrotate needs a bit of free space to create temporary files during rotation. If the disk is already full, rotation fails and the problem gets worse. First, check disk usage to see where space is going. Use the du command and the df command to identify the largest files and overall partition usage.

Then free enough space to let rotation work:

# Truncate the biggest offender (keeps the file handle open)
sudo truncate -s 0 /var/log/huge-offending.log

# Now force rotation
sudo logrotate -f /etc/logrotate.conf

Corrupted State File

If the state file gets corrupted (power loss, disk errors), logrotate may skip files it should rotate. The fix is simple:

sudo rm /var/lib/logrotate/status
sudo logrotate -f /etc/logrotate.conf

This forces a fresh rotation of everything. The state file gets recreated automatically.

Application Not Releasing File Handles

This is the sneaky one. After rotation, an application might keep writing to the old (now renamed) log file because it still has the file handle open. You can spot this with the lsof command to see which process has the file open. Use tail -F command (capital F) instead of tail -f to follow logs through rotations.

Two fixes:

• copytruncate: Avoids the file handle problem entirely
• postrotate reload: Signals the application to reopen its log file

You can check if logrotate.timer is active with systemctl to make sure rotation is even being triggered.

Best Practices for Production Systems

After managing everything from single-server homelabs to multi-node production clusters, here’s what I always set up on day one. Think of this like setting up automated backups: the best time to configure it is before you need it.

Use Size Limits with Time-Based Rotation

Don’t rely on time alone. Combine daily or weekly with maxsize so burst traffic can’t fill your disk between scheduled rotations:

daily
maxsize 500M
minsize 1M
rotate 14

The minsize 1M prevents rotating near-empty files. No point compressing a 2 KB log.

Always Test Configurations in Dry Run

Make it a habit. Every new config gets a logrotate -d before it goes live. Every time. No exceptions. I cannot stress this enough. A comprehensive logrotate guide will tell you the same thing.

Monitor Disk Space Proactively

Log rotation is reactive by design. It only runs when triggered by cron. Pair it with proactive monitoring:

• Set up disk usage alerts at 80% and 90% thresholds
• Use tools like Prometheus + node_exporter for real-time tracking
• Schedule regular disk usage checks with cron

Document Your Rotation Policies

Future you (or whoever inherits your servers) will thank you. Add comments to every custom config file explaining why you chose specific values:

# Custom rotation for payment service logs
# Retain 30 days for PCI compliance
# maxsize 200M: this service logs heavily during sales events
/var/log/payment-service/*.log {
    daily
    maxsize 200M
    rotate 30
    compress
    delaycompress
    ...
}

Take Control of Your Logs Before They Take Control of You

Logrotate is one of those Linux tools that does exactly one thing and does it well. Once configured, it runs quietly in the background, compressing old logs, deleting expired ones, and keeping your disk space healthy. The 15 minutes you spend setting it up today could save you hours of emergency cleanup later.

Start with your highest-volume log files. Run du -sh /var/log/* to find the biggest offenders. Write a config, test it with -d, deploy it, and move on to the next one. Within an hour, you’ll have a solid rotation policy across your entire system.

If you’re dealing with a disk space emergency right now, head over to our disk-full troubleshooting guide first, then come back here to prevent it from happening again. For more Linux administration fundamentals, check out our guides on scheduling cron jobs and monitoring disk usage.

Alexa Velinxs

I'm Alexa Velinxs, a cryptocurrency trading expert passionate about demystifying digital assets for both beginners and seasoned investors. Through my writing, I share actionable strategies, market insights, and practical tips to help you navigate the crypto landscape with confidence. Let's explore the future of finance together.

See Full Bio