logrotate: Configure Log Rotation on Linux

Log management is a fundamental pillar for any Linux system administrator. Without an effective strategy, log files can grow excessively, saturating disk space, compromising system performance, and making it difficult to analyze critical events or troubleshoot problems. In an enterprise environment, where hundreds of servers generate terabytes of data daily, a full disk due to unmanaged logs can halt entire services, leading to significant operational costs.

logrotate is the standard tool on Linux for automating the rotation, compression, and removal of log files. It allows you to define precise rules for each application, ensuring that logs are always available for analysis but without occupying unnecessary space. Incorrect logrotate configuration is one of the most common causes of full disks I’ve encountered in environments with 2,000 workstations and 300+ VMware VMs, and proper implementation can prevent service interruptions and greatly simplify debugging and monitoring work.

Tested on: Ubuntu 24.04 LTS · logrotate 3.21.0 · October 2026

Prerequisites / Test Environment

To follow this guide, you will need a Linux system (preferably Ubuntu or Debian, but the concepts apply to any distribution) with sudo privileges. logrotate is pre-installed on most modern Linux systems. We will use a fictitious application called app that writes its logs to /var/log/app/ and has a systemd service named app that needs to be reloaded after log rotation.

How logrotate Works and When It Runs

logrotate is a utility that runs in the background, usually invoked by cron. On many distributions, there is a file /etc/cron.daily/logrotate that executes the command logrotate /etc/logrotate.conf once a day. The /etc/logrotate.conf file contains global configurations and includes all files in the /etc/logrotate.d/ directory. It is in this latter directory that we will create specific configuration files for our applications.

When logrotate runs, it reads the configurations and checks if it’s time to rotate logs based on the defined rules (e.g., daily, weekly, by size). If a rotation is necessary, it proceeds with the specified actions: renames the current log file, creates a new one (or empties it), compresses it, and removes older copies.

Application Configuration File

Each application or service that generates logs can have its own dedicated configuration file in /etc/logrotate.d/. This modular approach simplifies management and maintenance. Let’s create an example for our fictitious app:

# /etc/logrotate.d/app
/var/log/app/*.log {
    daily
    rotate 14
    compress
    delaycompress
    missingok
    notifempty
    create 0640 app app
    postrotate
        systemctl reload app
    endscript
}

Let’s analyze the main directives:

• /var/log/app/.log: Specifies the log files to which the rules apply. The asterisk () indicates all files with the .log extension within the /var/log/app/ directory.
• daily: Rotation will occur every day. Other common options are weekly, monthly, yearly.
• rotate 14: 14 copies of the rotated logs will be kept. After the fourteenth rotation, the oldest copy will be deleted.
• compress: Compresses rotated logs (usually with gzip).
• delaycompress: Delays the compression of a rotated log until the next cycle. Useful if the service might still write to the newly rotated file for a short period.
• missingok: Does not generate an error if the log file does not exist.
• notifempty: Does not rotate the log if it is empty.
• create 0640 app app: Creates a new log file with 0640 permissions and app:app owner/group after rotation. This is the preferred option when the service is able to reopen the new log file.

Frequency, Number of Copies, and Compression

The choice of rotation frequency (daily, weekly, monthly, yearly) depends on the volume of logs generated and the need for analysis. For high-traffic services, daily is often the best choice. The rotate N parameter defines for how many cycles the rotated logs will be kept. For example, rotate 7 with daily means you will have 7 days of compressed historical logs.

The compress directive is almost always advisable to save disk space. delaycompress is particularly useful in environments where services might maintain an open handle on the log file for a short period after rotation. This way, the file is renamed in the first cycle and compressed only in the second, avoiding concurrent access issues.

copytruncate or create: The Difference That Matters

This is one of the most critical points in logrotate configuration and often a source of errors. The choice between copytruncate and create depends on how the application manages its log files.

• create (default if not specified and copytruncate is not used): logrotate moves the current log file (e.g., from app.log to app.log.1) and creates a new empty app.log file. This is the most efficient option. However, it requires the application to be able to reopen the new log file. If the application continues to write to the renamed file, new events will be lost or written to an ‘old’ file that will no longer be properly monitored. To remedy this, the postrotate directive is used.
• copytruncate: logrotate creates a copy of the current log file and then empties the original file. The service continues to write to the original file, which has been emptied. This method is less efficient (requires more I/O) but is safer for applications that cannot be easily restarted or do not support log reopening. It does not require a postrotate to make the service reopen the log, but it can cause the loss of some log events between the copying and emptying of the file.

Read also: Linux find Command: 20 Practical Examples

postrotate: Making the Service Reopen Logs

As mentioned, if you use the create directive (or if you don’t use copytruncate), it is essential to let the service know that its log file has been moved and that it must start writing to a new file. This is done with the postrotate directive.

    postrotate
        systemctl reload app
    endscript

The postrotate/endscript block contains commands that will be executed after the rotation has occurred. In this case, systemctl reload app sends a reload signal to the app service. Many services (like nginx, apache, rsyslog) are designed to reopen their log files when they receive a SIGHUP signal (which systemctl reload often sends). It is crucial to check the service documentation to understand which command is most appropriate to make it reopen logs without interrupting the service. Read also: systemd Service Creation: Auto-Restart & Dependencies

Rotate by Size Instead of Date

In addition to time-based rotation, logrotate also supports file size-based rotation. This is particularly useful for services that generate a highly variable or extremely high volume of logs, where a daily rotation might be insufficient or excessive.

/var/log/another_app/*.log {
    size 100M
    rotate 5
    compress
    postrotate
        systemctl reload another_app
    endscript
}

The size 100M directive indicates that the log will be rotated when it reaches 100 Megabytes. You can use K for Kilobytes, M for Megabytes, and G for Gigabytes. If both size and a time frequency (daily, etc.) are specified, logrotate will rotate the log whenever one of the two conditions is met.

Test Configuration Without Touching Files

Before implementing a new configuration in production, it is essential to test it. logrotate offers debug modes that simulate execution without making changes to real files.

For a debug mode execution:

sudo logrotate -d /etc/logrotate.d/app

This command will show what logrotate would do, including why a log would or would not be rotated, and which postrotate commands would be executed. It is a valuable tool for troubleshooting.

To force a rotation (useful for testing postrotate or freeing up space in an emergency):

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

This will ignore frequency and size conditions and force the rotation of the specified logs. Use it with caution in production, as it might trigger postrotate and reload the service at an inopportune time.

Finally, to check the status of logrotate rotations (when a specific log was last rotated):

cat /var/lib/logrotate/status

This file contains information on the last time each log was rotated, essential for verifying that logrotate is working as expected.

Common Errors and Troubleshooting

1. Logs not rotating: Check that the configuration file is in /etc/logrotate.d/ and that it is called by /etc/logrotate.conf. Verify that the logrotate cronjob is active (/etc/cron.daily/logrotate). Check the permissions of the log files and directories. A common error is that logrotate does not have permissions to write to the log directory or to rename files. Read also: AD Trust Relationship: Fix Workstation Domain Errors
2. Service not reopening the log: If you use create and the service does not reopen the log, new events will be lost. Ensure that the command in the postrotate block is correct and that the service is configured to respond to the appropriate signal (e.g., SIGHUP). Test it with sudo logrotate -f.
3. Corrupted log files with copytruncate: If a service writes constantly and intensely, copytruncate can lead to corrupted or incomplete logs, as there is a small interval between copying and emptying during which the service might write. In these cases, create with a robust postrotate is preferable.
4. Incorrect permissions on new logs: If the new log file is created with wrong permissions, the service might not be able to write to it. Use the create MODE OWNER GROUP directive to specify the correct permissions.

FAQ — Frequently Asked Questions

Do I need to restart the service after modifying logrotate?

No, it is not necessary to restart the logrotate service itself. Changes to configuration files in /etc/logrotate.d/ are read every time logrotate is executed by the daily cronjob. However, if you have modified the postrotate block for a specific application, you might want to force a rotation with sudo logrotate -f /etc/logrotate.d/app to ensure that the postrotate command is executed and tested immediately.

What is the difference between compress and delaycompress?

compress immediately compresses the newly rotated log file. delaycompress delays the compression by one rotation cycle. This means that the app.log.1 file (the newly rotated log) will remain uncompressed until the next logrotate execution, when it will be compressed into app.log.1.gz. This is useful for services that might still read from the newly rotated file for a short period, avoiding access errors to compressed files.

Can I use logrotate to rotate Docker logs?

Yes, it is possible. Docker logs are usually managed through the logging driver configured for the containers. However, if your containers write logs to files on the host filesystem, you can configure logrotate for those files. A common approach is to configure Docker’s logging driver (e.g., json-file with max-size and max-file) and then use logrotate to manage the Docker daemon logs themselves, which are typically found in /var/lib/docker/containers/ or similar.

How can I exclude a certain type of log from rotation?

logrotate allows specifying inclusion and exclusion patterns. If you have a generic pattern like *.log but want to exclude debug.log, you can use the tabooext directive in the main configuration file /etc/logrotate.conf or a specific configuration file with a more precise inclusion pattern. In general, it is better to be specific with inclusion patterns to avoid unwanted rotations.

Conclusions with Operational Takeaways

Proper logrotate configuration is an operation that, once set up, will save you countless headaches related to full disks and data loss. Always remember to:

1. Create dedicated configuration files for each application in /etc/logrotate.d/.
2. Carefully choose between copytruncate and create, based on your service’s behavior.
3. Always implement a postrotate block to make services reopen logs when using create.
4. Test every new configuration with sudo logrotate -d before applying it in production.
5. Monitor the /var/lib/logrotate/status file to ensure rotations occur regularly.

Proactive log management is not just good practice, but an indispensable requirement for the stability and security of any Linux infrastructure.

Sources

• logrotate man page
• Systemd documentation

Updated: October 2026