How to Configure logrotate on a Linux VPS: A Practical Guide to Log File Management

Log files are an essential tool for any server administrator: they tell you what's happening with your services, where errors occur, and who's attempting unauthorized access. The problem? Left unmanaged, log files can grow to fill every byte of available disk space — a classic scenario that can bring down a production server.

The elegant solution is logrotate — a standard Linux utility that automates the rotation, compression, and deletion of old log files. In this guide, you'll learn how to configure it correctly on your Linux VPS, whether you're running Nginx, Apache, MySQL, or custom applications.

What Is logrotate and Why Do You Need It

Logrotate is a standard tool pre-installed on most Linux distributions (Ubuntu, Debian, CentOS, AlmaLinux). It works based on a central configuration file and individual configuration files for each service.

Without logrotate, /var/log/nginx/access.log can reach tens of gigabytes within a few months on a server with moderate traffic. On an SSD VPS with limited storage, that means downtime.

With logrotate, you define simple rules:
- rotate logs daily/weekly/monthly
- keep the last N copies
- compress old files
- send signals to services after rotation (e.g., reload for Nginx)

Verifying and Installing logrotate

On most servers, logrotate is already installed. Verify:

logrotate --version

If it's not installed:

# Ubuntu/Debian
sudo apt update && sudo apt install logrotate -y

# CentOS/AlmaLinux
sudo yum install logrotate -y

The main configuration file is at /etc/logrotate.conf, with per-service configurations in the /etc/logrotate.d/ directory.

Configuration File Structure

Open the main file:

sudo nano /etc/logrotate.conf

Typical content:

# Default weekly rotation
weekly

# Keep 4 weeks of logs
rotate 4

# Create new log files after rotation
create

# Compress old logs
compress

# Include service-specific configs
include /etc/logrotate.d

These values are global — they apply to all services that don't have their own specific options.

Configuring logrotate for Nginx

The file /etc/logrotate.d/nginx usually exists after installing Nginx. Here's what an optimal configuration looks like:

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

Option explanations:
- daily — daily rotation
- rotate 14 — keep 14 days of logs
- compress — compress old files with gzip
- delaycompress — delay compression by one rotation cycle (useful for services that write asynchronously)
- notifempty — don't rotate if the file is empty
- missingok — don't error if the file is missing
- postrotate — command executed after rotation; here we send USR1 to Nginx to reopen log files

Configuring logrotate for Apache

/var/log/apache2/*.log {
    weekly
    missingok
    rotate 8
    compress
    delaycompress
    notifempty
    create 640 root adm
    sharedscripts
    postrotate
        if invoke-rc.d apache2 status > /dev/null 2>&1; then
            invoke-rc.d apache2 reload > /dev/null 2>&1
        fi
    endscript
}

Same logic — after rotation, Apache receives a reload signal so it starts writing to the new log file.

Configuring logrotate for MySQL/MariaDB

MySQL logs can grow rapidly on servers with heavy query loads:

/var/log/mysql/mysql.log /var/log/mysql/mysql-slow.log /var/log/mysql/error.log {
    daily
    rotate 7
    missingok
    compress
    delaycompress
    notifempty
    sharedscripts
    postrotate
        test -x /usr/bin/mysqladmin || exit 0
        MYADMIN="/usr/bin/mysqladmin --defaults-file=/etc/mysql/debian.cnf"
        if [ -f `$MYADMIN variables 2>/dev/null | awk '/pid_file/ { print $4 }'` ]; then
            $MYADMIN flush-logs
        fi
    endscript
}

On a managed dedicated server, this configuration is typically already optimized by the management team. On an unmanaged server, configuration responsibility falls entirely on you.

Custom Configuration for Your Own Applications

If you have an application writing its own logs (e.g., /var/log/myapp/app.log), create a new file:

sudo nano /etc/logrotate.d/myapp

/var/log/myapp/*.log {
    weekly
    rotate 12
    compress
    delaycompress
    missingok
    notifempty
    create 0644 appuser appgroup
    dateext
    dateformat -%Y-%m-%d
}

The dateext and dateformat options append the date to rotated filenames instead of the default numeric suffix (.1, .2), making them much easier to identify.

Testing Your Configuration

Before letting logrotate run automatically, test your configuration:

# Simulation (dry-run) — makes no actual changes
sudo logrotate --debug /etc/logrotate.conf

# Force rotation for a specific file
sudo logrotate --force /etc/logrotate.d/nginx

Check logrotate's status file:

cat /var/lib/logrotate/status

Here you'll see the date of the last rotation for each monitored log file.

Automation with cron

Logrotate usually runs automatically via a daily cron job. Verify:

cat /etc/cron.daily/logrotate

If you want to schedule rotation at a specific time (rather than the random window within cron.daily), add an explicit job:

sudo crontab -e

# Rotate logs every night at 02:00
0 2 * * * /usr/sbin/logrotate /etc/logrotate.conf

This is particularly useful on dedicated servers with heavy traffic, where you need precise control over the rotation timing.

Common Mistakes and How to Avoid Them

1. Forgetting to signal the service after rotation

If Nginx or Apache continue writing to the old (renamed) file, new logs won't appear in the current file. Always include the postrotate block.

2. Compressing files that are still open

Use delaycompress together with compress to avoid this issue.

3. Incorrect permissions on new files

The create option must specify the correct permissions and owner, otherwise the service won't be able to write to the new file:

create 0640 www-data adm

4. Not verifying configuration after changes

Run logrotate --debug after any modification to catch errors before the cron job runs automatically.

Monitoring Disk Space After Configuration

After setting up logrotate, periodically check the space occupied by logs:

du -sh /var/log/*

Or sort by size:

du -sh /var/log/* | sort -rh | head -20

If you use our server management services, the CLIQHOST team can configure logrotate, monitor disk space, and proactively alert you to any issues before they become critical.

For more practical Linux administration guides, check out the CLIQHOST blog.

Conclusion

Logrotate is a simple but essential utility for any Linux server running in production. A correct configuration guarantees that log files won't consume all your storage space and that important information is retained in an organized manner for exactly as long as you need it.

In summary:
- Check and customize the files in /etc/logrotate.d/
- Test with --debug before going to production
- Make sure services receive the reload signal after rotation
- Regularly check /var/lib/logrotate/status

If you need a stable, high-performance Linux environment to apply these configurations, explore CLIQHOST's NVMe VPS plans — with fast NVMe storage, dedicated IPv4, and full root access. Have questions? Contact our team — we're here to help.

How to Configure logrotate on a Linux VPS: A Practical Guide to Log File Management