Configuring logrotate: A Complete Guide to Log Management in Linux

Introduction

Logrotate is a utility for automatic log file management in Linux. It prevents uncontrolled log growth, which could fill up the entire disk and lead to system failures. With logrotate, you can configure regular log rotation (renaming old logs), compression of archives, and deletion of outdated data. Once configured, the process becomes fully automated, saving you time and disk space.

Requirements / Preparation

Before you begin, ensure that:

• The logrotate package is installed on your system (usually present by default).
• You have superuser privileges (sudo) to edit configuration files in /etc/.
• You know the paths to the log files you want to rotate (e.g., /var/log/nginx/access.log).
• A basic understanding of Linux directory structure and text editors (nano, vim) is recommended.

Step 1: Check Logrotate Installation

Open a terminal and run:

logrotate --version

If you see a version (e.g., logrotate 3.18.0), the utility is installed. If the command is not found, install it:

For Debian/Ubuntu:

sudo apt update
sudo apt install logrotate

For RHEL/CentOS/Fedora:

sudo yum install logrotate   # CentOS/RHEL 7
sudo dnf install logrotate   # CentOS/RHEL 8+, Fedora

⚠️ Important: On most modern distributions, logrotate is preinstalled. Installation is rarely required.

Step 2: Understanding Configuration File Structure

Logrotate uses two types of configurations:

1. Main file — /etc/logrotate.conf. It contains global settings (e.g., run frequency) and can include other configs.
2. Application files — in the /etc/logrotate.d/ directory. Each file handles log rotation for a specific service or application.

Look at the examples:

ls /etc/logrotate.d/

You will see files for apt, dpkg, rsyslog, and others. This helps understand the syntax.

Open the main config:

sudo cat /etc/logrotate.conf

Typical contents:

# see "man logrotate" for details
weekly
rotate 4
create
include /etc/logrotate.d

Here, weekly is the global rotation frequency (if not overridden in local configs), rotate 4 means keep 4 archives, and include pulls in configs from /etc/logrotate.d/.

Step 3: Create a Configuration File for Your Application

Assume your application writes logs to /var/log/myapp/ (files app.log, error.log). Create the config:

sudo nano /etc/logrotate.d/myapp

Paste the basic configuration:

/var/log/myapp/*.log {
    daily
    rotate 7
    compress
    delaycompress
    missingok
    notifempty
    create 644 root root
    sharedscripts
    postrotate
        systemctl restart myapp.service > /dev/null 2>&1 || true
    endscript
}

Brief parameter description:

• /var/log/myapp/*.log — log file pattern.
• daily — rotate every day.
• rotate 7 — keep 7 archives (older ones will be deleted).
• compress — compress archives with gzip.
• delaycompress — delay compression until the next rotation (so the application can still write to the not-yet-compressed file).
• missingok — don't throw an error if the log file is missing.
• notifempty — don't rotate empty files.
• create 644 root root — create a new log file with permissions 644 and owner root:root.
• sharedscripts — postrotate/prerotate scripts run once for the entire set of files.
• postrotate...endscript — commands after rotation (here, restarting the service so it writes to the new log).

Save the file (Ctrl+X, then Y and Enter in nano).

Step 4: Configuring Rotation Parameters

The configuration from Step 3 is a good base, but parameters should be adapted to your needs. Here are key options:

Example for size-based rotation:

/var/log/myapp/*.log {
    size 100M
    rotate 5
    compress
    missingok
    notifempty
    create 644 root root
}

Here, logs will rotate as soon as they reach 100 MB, but not more than once per day (if no frequency is specified).

Step 5: Testing the Configuration

Before deploying to production, test the config:

sudo logrotate -d /etc/logrotate.conf

The -d (debug) flag shows what actions would be taken without making changes. Output will contain lines like:

reading config file /etc/logrotate.conf
including /etc/logrotate.d
...
rotating pattern: /var/log/myapp/*.log  after 1 days (7 rotations)
empty log files are not rotated, old logs are removed
...

If there are errors (e.g., "error: bad directive"), fix the config.

Step 6: Forcing a Run and Automation

For immediate rotation (e.g., to test), run:

sudo logrotate -f /etc/logrotate.conf

The -f (force) flag ignores time constraints.

Automation: Logrotate is typically run daily via cron. Check the task:

ls /etc/cron.daily/logrotate

If the file exists, cron will run logrotate automatically (usually at 6:25 AM). To change the time, edit the file or configure an alternative via systemd timer (on modern systems).

Verifying the Result

1. Navigate to the log directory:

   ls -lh /var/log/myapp/
   

2. You should see:
   • The active log file (e.g., app.log).
   • Compressed archives (e.g., app.log.1.gz, app.log.2.gz, etc.) depending on the rotate setting.
3. Check sizes: the active log should be small (if rotation occurred), archives should be compressed.
4. Also check the system log for any logrotate errors:

   sudo grep logrotate /var/log/syslog
   

Common Issues

Permission Errors on Log Files

💡 If Permission denied appears in logs or when running logrotate, ensure:

• Log files are readable by the user running logrotate (usually root).
• The config specifies the correct owner in create (e.g., create 644 www-data www-data for a web server).

Logs Not Rotating on Schedule

• Check if cron is running: sudo systemctl status cron (Debian/Ubuntu) or sudo systemctl status crond (RHEL/CentOS).
• Ensure /etc/cron.daily/logrotate exists and is executable (ls -l /etc/cron.daily/logrotate).
• If using a systemd timer, check: sudo systemctl status logrotate.timer.

Compression Not Happening

• Ensure gzip is installed (usually present by default). Check: which gzip.
• The config must include compress (or delaycompress).
• To use other algorithms (bzip2, xz), specify compresscmd (e.g., compresscmd /usr/bin/bzip2).

Application Continues Writing to Old Log After Rotation

This is a common problem: after renaming the log file, the application doesn't realize it and continues writing to the old file descriptor. Solution:

• In the postrotate block, add a command to reopen logs. For example, for nginx:

  postrotate
      [ ! -f /var/run/nginx.pid ] || kill -USR1 `cat /var/run/nginx.pid`
  endscript
  

• For systemd services, systemctl restart service often works but may cause brief downtime. An alternative is kill -HUP (if the application supports it).

Configuration Conflicts

• Logrotate processes files in /etc/logrotate.d/ in alphabetical order. If two configs target the same log file, the last one (alphabetically) wins. Avoid duplication.
• Global settings from /etc/logrotate.conf apply only if not overridden in a local config.