Master Log Rotation with logrotate: Keep Your Servers Clean and Efficient

When you need to track application usage or troubleshoot issues, logs are invaluable, but as they grow they can consume disk space, slow down server resizing or backups, and make it hard to locate specific events, so keeping log sizes manageable and deleting old logs is essential.

Fortunately, the logrotate tool simplifies log rotation, which archives the current log, starts a new one, and removes old logs. Systems typically run logrotate daily, checking custom rules for each directory or log.

How logrotate works

Logrotate is scheduled, usually daily via a script in /etc/cron.daily/logrotate (or /etc/cron.daily/logrotate.cron on Gentoo). For more frequent runs, such as hourly, you can place a script under /etc/cron.hourly. When executed, logrotate reads its configuration to determine which logs to rotate, how often, and how many archives to keep.

logrotate.conf

The main configuration file resides at /etc/logrotate.conf and defines default parameters for log rotation. It contains comments for guidance. Notably, it includes the line: include /etc/logrotate.d This directory holds most application‑specific configuration files.

logrotate.d

List the contents of the directory with: ls /etc/logrotate.d The directory may be empty or contain many files, depending on installed packages. Packages typically create a config file here; for example, a syslog service configuration is often present, defining system log entries and inheriting commands from logrotate.conf.

Note: Ubuntu versions prior to 9.10 (Karmic Koala) did not have a syslog entry; log rotation was performed by the savelog command from /etc/cron.daily/sysklogd .

Diving into application configuration files

Consider a logrotate configuration that might be installed when you add Apache on a Fedora system:

/var/<span>log</span>/httpd/*log {
    missingok
    notifempty
    sharedscripts
    postrotate
    /sbin/service httpd reload > /dev/null 2>/dev/null || true
    endscript
}

When logrotate runs, it checks /var/log/httpd for non‑empty files ending with log and rotates them. If no such files exist, no error occurs. After processing all specified logs, it executes the postrotate block, which in this example restarts Apache.

This example does not include some defaults from logrotate.conf; those defaults apply unless overridden. You can override defaults per application, such as setting daily for a busy web service to rotate Apache logs daily instead of the default weekly.

The next sections introduce common configuration directives.

Configuration directives

You can view the full list of directives with the manual: man logrotate This section highlights the most frequently used commands. Remember that files in /etc/logrotate.d inherit defaults from /etc/logrotate.conf.

Log files

Define log files and their rotation behavior by listing one or more files followed by a block of commands in curly braces. Most application configs contain a single block, but multiple blocks are allowed, and blocks can also be placed in logrotate.conf.

You can use wildcards or space‑separated lists to specify multiple files. For example:

/var/foo/*.log /var/bar/log.txt {
        rotate 14
        daily
        compress
        delaycompress
        sharedscripts
        postrotate
                /usr/sbin/apachectl graceful > /dev/null
        endscript
}

Rotate count

The rotate directive sets how many archived logs to retain before deleting the oldest: rotate 4 This tells logrotate to keep four archives; when a fifth rotation occurs, the oldest archive is removed.

Rotation interval

You can specify how often to rotate logs using commands such as:

daily
weekly
monthly
yearly

If no interval is set, logs are rotated each time logrotate runs (unless other directives like size apply).

For non‑standard intervals, create a separate configuration and invoke it via cron. For hourly rotation, place a file in /etc/cron.hourly containing: /usr/sbin/logrotate /etc/logrotate.hourly.conf Then put the hourly‑specific logrotate settings in /etc/logrotate.hourly.conf.

Size

The size directive lets you rotate based on file size, using units like k, M, or G:

size 100k
size 100M
size 100G

The first example rotates when the log exceeds 100 KB, the second at 100 MB, and the third at 100 GB (generally not recommended). When both size and an interval are set, size takes precedence.

Compression

To compress archived logs with gzip, include the compress command (usually in /etc/logrotate.conf): compress Compression is advisable because log files are plain text and compress well. If you want certain logs not to be compressed while keeping compression as the default, add nocompress in the specific application's config. nocompress Another useful command is delaycompress, which postpones compression until the next rotation. This is helpful when a program may still write to the old log after rotation, such as Apache during a graceful reload.

delaycompress

Postrotate

Logrotate runs the postrotate script after rotating the logs defined in a block, typically to restart the associated application:

postrotate
    /usr/sbin/apachectl restart > /dev/null
endscript

The redirection > /dev/null discards the command’s output.

Sharedscripts

By default, postrotate runs after each individual log is rotated. With the sharedscripts directive, the script runs only once per block if any log in the block was rotated: sharedscripts This prevents multiple restarts when several logs share the same configuration.

Where to go next

This article has outlined logrotate’s capabilities and configuration options. You should now be able to examine existing configurations and adapt them to your needs. For sample configurations and troubleshooting, refer to “Sample logrotate configurations and troubleshooting.”