How to Configure Log Rotation using logrotate on Linux Servers

Introduction

Linux applications and system daemons continuously generate log files. If left unchecked, files like /var/log/syslog or Apache’s access.log can grow to hundreds of gigabytes, eventually consuming all available disk space and crashing the server. The standard solution in Linux is logrotate, a system utility designed to automatically compress, rename, delete, and email log files at specified intervals. This guide explains how to configure logrotate for custom applications.

Understanding How logrotate Works

logrotate is typically executed daily via a cron job (located in /etc/cron.daily/logrotate). It reads its main configuration file from /etc/logrotate.conf, and then processes individual application-specific configuration files stored in the /etc/logrotate.d/ directory.

Step 1: Create a Custom Configuration File

To rotate logs for a custom application, you should create a new file in the /etc/logrotate.d/ directory rather than editing the main configuration file.

Suppose you have a custom Node.js application writing logs to /var/log/myapp/app.log. Create a new configuration file:

sudo nano /etc/logrotate.d/myapp

Step 2: Define the Rotation Directives

Paste the following configuration block into the file and adjust it to your needs. This block tells logrotate exactly what to do with the target log file.

/var/log/myapp/*.log {
    daily
    rotate 7
    compress
    delaycompress
    missingok
    notifempty
    create 0640 myuser mygroup
    postrotate
        systemctl reload myapp > /dev/null 2>&1 || true
    endscript
}

Step 3: Explaining the Directives

Here is what each directive accomplishes:

• daily: Rotates the logs every day. You can also use weekly, monthly, or size-based triggers like size 50M.
• rotate 7: Keeps exactly 7 rotated log files (e.g., app.log.1, app.log.2) before deleting the oldest one.
• compress: Uses gzip to compress rotated logs to save disk space.
• delaycompress: Postpones compression until the second rotation. This is useful if your application takes a few seconds to release the file handle on the old log file.
• missingok: Do not output an error if the log file is missing.
• notifempty: Do not rotate the log if it is completely empty.
• create 0640 myuser mygroup: Immediately after rotating, create a brand new, empty app.log file with these specific permissions and ownership so the application can continue writing.
• postrotate / endscript: Executes a shell command after the rotation completes. This is critical for applications that hold log files open in memory. The systemctl reload command forces the app to close the old file handle and write to the newly created file.

Step 4: Test the Configuration

Before waiting for the daily cron job, you should test your configuration to ensure there are no syntax errors.

Run logrotate in debug mode (-d). This simulates the rotation process without actually moving or compressing any files:

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

Review the output to confirm it correctly identifies the logs and plans the rotation. If you want to force the rotation to happen immediately, bypassing the daily timer, use the force (-f) flag:

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