Rotate Logs Linux: How to Manage Logs With Logrotate

If you need to rotate logs Linux, the standard tool to use is logrotate. It automatically rotates, compresses, removes, and manages old log files so they do not consume all available disk space.

Linux servers can generate thousands of log entries every day. Web servers, applications, authentication services, databases, firewalls, and system processes can all create logs. Without proper Linux log rotation, these files can grow until they affect server storage and performance.

This guide explains how to rotate logs in Linux using logrotate, create custom rules, test configurations, force rotation, and troubleshoot common problems.

What Is Linux Log Rotation?

Linux log rotation is the process of regularly moving, compressing, renaming, or deleting old log files while keeping the current log available for new entries.

For example, a server may have a file such as:

/var/log/example.log

/var/log/example.log

After rotation, the system could have:

example.log
example.log.1
example.log.2.gz
example.log.3.gz

example.log
example.log.1
example.log.2.gz
example.log.3.gz

The newest file continues receiving log entries while older logs are retained for a defined period.

The logrotate utility is designed specifically for this purpose. It can rotate logs based on time or file size and can also compress and remove older files.

Why Is Log Rotation Important?

Without rotation, a frequently updated log can become extremely large.

This creates several problems:

Log rotation keeps active logs manageable while preserving older entries for troubleshooting and auditing.

How Does Logrotate Work in Linux?

logrotate reads configuration files that define how individual logs should be handled.

The main configuration file is:

/etc/logrotate.conf

/etc/logrotate.conf

Additional application-specific configurations are commonly stored in:

/etc/logrotate.d/

/etc/logrotate.d/

For example:

/etc/logrotate.d/nginx

/etc/logrotate.d/nginx

A typical configuration can define:

• How often a log is rotated
• How many old files are retained
• Whether old logs are compressed
• Whether empty logs should be skipped
• Whether a command should run after rotation
• Whether a service needs to reload its log file

On systems using systemd, logrotate may be triggered by a timer. Traditional installations may use a daily cron job.

Common Logrotate Options

The exact behavior depends on the directives used in the configuration.

Where Is the Logrotate Configuration in Linux?

There are two locations you should check first.

Main Configuration

/etc/logrotate.conf

/etc/logrotate.conf

This file contains global settings and can also include additional configuration files.

Application Configurations

/etc/logrotate.d/

/etc/logrotate.d/

List the available configurations with:

ls -lah /etc/logrotate.d/

ls -lah /etc/logrotate.d/

You may see files for services such as:

nginx
apache2
mysql-server
rsyslog

nginx
apache2
mysql-server
rsyslog

The exact files depend on the software installed on your server.

To inspect the main configuration:

sudo cat /etc/logrotate.conf

sudo cat /etc/logrotate.conf

To inspect an application-specific rule:

sudo cat /etc/logrotate.d/nginx

sudo cat /etc/logrotate.d/nginx

Do not edit an existing application configuration unless you understand why it was created. A package update may also replace or modify configuration files.

How to Check Linux Log Rotation Configuration

Before changing anything, inspect the current configuration.

Start with:

sudo logrotate -d /etc/logrotate.conf

sudo logrotate -d /etc/logrotate.conf

The -d option enables debug mode. It shows what logrotate would do without actually rotating the files.

For more detailed output, you can use:

sudo logrotate -dv /etc/logrotate.conf

sudo logrotate -dv /etc/logrotate.conf

This is useful when you are troubleshooting linux log rotate behavior.

You can also check whether a systemd timer exists:

systemctl list-timers | grep logrotate

systemctl list-timers | grep logrotate

On systems using the timer, you may see a scheduled logrotate service.

To check its status:

systemctl status logrotate.timer

systemctl status logrotate.timer

If your distribution uses cron instead, inspect the relevant scheduled task.

How to Create a Custom Linux Log Rotation Rule

You can create a custom configuration inside:

/etc/logrotate.d/

/etc/logrotate.d/

Suppose your application writes logs to:

/var/log/myapp/*.log

/var/log/myapp/*.log

Create a configuration file:

sudo nano /etc/logrotate.d/myapp

sudo nano /etc/logrotate.d/myapp

Add:

/var/log/myapp/*.log {
    daily
    rotate 7
    compress
    delaycompress
    missingok
    notifempty
    create 0640 root adm
}

/var/log/myapp/*.log {
    daily
    rotate 7
    compress
    delaycompress
    missingok
    notifempty
    create 0640 root adm
}

This configuration tells logrotate to:

1. Check the application logs daily.
2. Keep seven rotations.
3. Compress older rotations.
4. Delay compression of the newest rotated file.
5. Ignore missing logs.
6. Skip empty files.
7. Create a new log file with the specified permissions.

The result may look similar to:

myapp.log
myapp.log.1
myapp.log.2.gz
myapp.log.3.gz

myapp.log
myapp.log.1
myapp.log.2.gz
myapp.log.3.gz

The exact file names can vary depending on your configuration and distribution.

Why Use Compression?

Old logs often contain valuable information but do not need to remain uncompressed.

The compress directive uses compression for rotated logs, reducing their storage footprint.

This is especially useful on servers that generate large access or error logs.

However, do not remove logs simply because they are old. Retention should match your troubleshooting, operational, and compliance requirements.

How to Rotate Logs Linux Manually

If you need to rotate logs in Linux immediately, you can run logrotate manually.

For a normal configuration run:

sudo logrotate /etc/logrotate.conf

sudo logrotate /etc/logrotate.conf

However, logrotate maintains state information to determine when a log was last rotated. As a result, running the command does not necessarily mean every configured log will rotate immediately.

If you want to test what would happen first, use:

sudo logrotate -d /etc/logrotate.conf

sudo logrotate -d /etc/logrotate.conf

This is safer than immediately forcing changes.

How to Force Log Rotation in Linux

Sometimes you need to rotate logs regardless of the normal schedule.

Use:

sudo logrotate -f /etc/logrotate.conf

sudo logrotate -f /etc/logrotate.conf

The -f option forces rotation.

Use this carefully on production servers. Forcing every configured log to rotate may trigger actions such as service reloads or scripts defined in configuration files.

A better approach is often to test first:

sudo logrotate -d /etc/logrotate.conf

sudo logrotate -d /etc/logrotate.conf

Then force the rotation if the result is expected:

sudo logrotate -f /etc/logrotate.conf

sudo logrotate -f /etc/logrotate.conf

How to Test Logrotate Without Changing Files

Testing is one of the most important parts of linux log rotation.

Use debug mode:

sudo logrotate -d /etc/logrotate.conf

sudo logrotate -d /etc/logrotate.conf

For verbose debug output:

sudo logrotate -dv /etc/logrotate.conf

sudo logrotate -dv /etc/logrotate.conf

The command shows which files logrotate finds, which rules apply, and whether a rotation would occur.

This lets you identify configuration problems before making changes to production logs.

Test a Specific Configuration

If you created:

/etc/logrotate.d/myapp

/etc/logrotate.d/myapp

you normally test the complete configuration through:

sudo logrotate -d /etc/logrotate.conf

sudo logrotate -d /etc/logrotate.conf

This allows included configurations to be evaluated in the same context as a normal logrotate run.

If the debug output shows unexpected behavior, fix the configuration before forcing rotation.

How to Check Whether Log Rotation Worked

After running a rotation, inspect the relevant directory.

For example:

ls -lah /var/log/myapp/

ls -lah /var/log/myapp/

You may see:

myapp.log
myapp.log.1
myapp.log.2.gz
myapp.log.3.gz

myapp.log
myapp.log.1
myapp.log.2.gz
myapp.log.3.gz

Check the timestamps:

ls -lah --time-style=long-iso /var/log/myapp/

ls -lah --time-style=long-iso /var/log/myapp/

You can also inspect the contents of a compressed log without extracting it:

zcat /var/log/myapp/myapp.log.2.gz

zcat /var/log/myapp/myapp.log.2.gz

For a large file, you can use:

zless /var/log/myapp/myapp.log.2.gz

zless /var/log/myapp/myapp.log.2.gz

This makes historical logs easier to inspect without manually extracting every compressed file.

How to Rotate Logs Based on File Size

Time-based rotation is not always enough.

A busy application could generate several gigabytes of logs before the next daily rotation.

You can use a size condition:

/var/log/myapp/*.log {
    daily
    size 100M
    rotate 7
    compress
    missingok
    notifempty
}

/var/log/myapp/*.log {
    daily
    size 100M
    rotate 7
    compress
    missingok
    notifempty
}

Here, the configuration checks the specified size condition as part of logrotate’s normal decision process.

For very active services, size-based rules can help prevent individual log files from becoming unnecessarily large.

Do not assume size and time-based directives always behave the way you expect when combined. Test the configuration with debug mode before deploying it.

What Is the Difference Between Size and Daily Rotation?

daily tells logrotate to consider the log on a daily schedule.

size introduces a size-based condition.

For example:

daily
size 100M

daily
size 100M

does not simply mean “rotate once every day and whenever the file reaches 100 MB.” The interaction between directives matters.

If your requirement is precise, test the actual configuration with:

sudo logrotate -d /etc/logrotate.conf

sudo logrotate -d /etc/logrotate.conf

This avoids guessing how the directives will behave together.

How Many Old Logs Should You Keep?

The rotate directive controls the number of old rotations retained.

For example:

rotate 7

rotate 7

keeps seven rotated files according to the configuration’s rotation cycle.

A weekly configuration might therefore retain several weeks of historical logs.

A daily configuration with seven rotations provides a shorter retention window.

Choose retention based on:

• Disk capacity
• Log volume
• Troubleshooting requirements
• Security monitoring needs
• Compliance requirements
• Backup strategy

There is no single retention number that is correct for every Linux server.

How to Handle Services That Keep Log Files Open

Some applications continue writing to the same file descriptor after a log has been renamed.

This can cause problems if the application does not reopen its log file after rotation.

One possible solution is copytruncate:

/var/log/myapp/*.log {
    daily
    rotate 7
    compress
    copytruncate
    missingok
    notifempty
}

/var/log/myapp/*.log {
    daily
    rotate 7
    compress
    copytruncate
    missingok
    notifempty
}

With copytruncate, logrotate copies the existing file and then truncates the original.

However, it is not always the ideal solution because there can be a small window between copying and truncating in which log entries may be lost.

When the application supports reopening its logs, a postrotate or prerotate action may be more appropriate.

For example:

postrotate
    systemctl reload myapp >/dev/null 2>&1 || true
endscript

postrotate
    systemctl reload myapp >/dev/null 2>&1 || true
endscript

The correct command depends on the application.

Never copy this example blindly into a production configuration. Confirm the service name and its supported log reload behavior first.

How to Troubleshoot Linux Log Rotation

If linux log rotation is not working, start with the configuration rather than immediately deleting files.

1. Run Debug Mode

sudo logrotate -dv /etc/logrotate.conf

sudo logrotate -dv /etc/logrotate.conf

Look for messages explaining why a file was skipped.

2. Check the Log Path

Make sure the configured path actually exists:

ls -lah /var/log/myapp/

ls -lah /var/log/myapp/

A typo in the path can prevent rotation.

3. Check File Permissions

Inspect ownership and permissions:

ls -lah /var/log/myapp/

ls -lah /var/log/myapp/

logrotate must have sufficient permissions to rename, create, compress, or remove files according to the configuration.

4. Check the State File

logrotate tracks rotation state so it knows when logs were last processed.

A common state file is:

/var/lib/logrotate/status

/var/lib/logrotate/status

The exact location can vary depending on how logrotate was installed or invoked.

5. Check the Scheduler

If manual rotation works but automatic rotation does not, check whether the scheduled job is running.

For systemd:

systemctl status logrotate.timer

systemctl status logrotate.timer

You can also inspect recent service activity:

journalctl -u logrotate --since "24 hours ago"

journalctl -u logrotate --since "24 hours ago"

6. Check Disk Space

A full filesystem can prevent new files from being created.

Run:

df -h

df -h

Then identify large directories:

sudo du -xh /var | sort -h | tail -20

sudo du -xh /var | sort -h | tail -20

This is especially important when a server is already experiencing disk pressure.

7. Check Inode Usage

A filesystem can also run out of inodes even when it still has free storage.

Run:

df -i

df -i

If inode usage is at or near 100%, investigate directories containing huge numbers of small files.

How to Prevent Logs From Filling Your Linux Server

Log rotation should be part of a broader log management strategy.

Do not simply rotate logs and forget about them.

Monitor:

• Log size
• Disk usage
• Retention periods
• Compression
• Application errors
• Authentication events
• Security events
• Backup requirements

CyberPanel also has a dedicated guide covering server log management, including monitoring, log rotation, and log backup practices.

For security-related events, logs can be especially useful when investigating suspicious activity. CyberPanel’s Linux hardening guide also discusses monitoring and logging as part of broader server security.

Log Rotation Best Practices

Follow these practices when configuring linux rotate logs rules.

Use a Dedicated Configuration File

Place custom rules in:

/etc/logrotate.d/

/etc/logrotate.d/

This keeps application-specific settings separate from the main configuration.

Test Before Forcing Rotation

Always use:

sudo logrotate -d /etc/logrotate.conf

sudo logrotate -d /etc/logrotate.conf

before:

sudo logrotate -f /etc/logrotate.conf

sudo logrotate -f /etc/logrotate.conf

Compress Older Logs

Use:

compress

compress

when historical logs do not need to remain uncompressed.

Keep a Reasonable Retention Period

Do not retain unlimited logs without considering storage capacity.

Avoid Blindly Using copytruncate

If the application supports a proper reload or reopen operation, that approach may be preferable.

Monitor Disk Usage

Use:

df -h

df -h

regularly or through server monitoring.

Protect Sensitive Logs

Logs can contain IP addresses, usernames, URLs, authentication information, and other sensitive operational data.

Restrict access to logs and make sure your retention and backup policies match your security requirements.

Keep Security and Log Management Separate

Log rotation does not secure a server by itself.

A firewall controls network access, while log rotation manages stored log files. If you are hardening a Linux server, review your firewall configuration separately. CyberPanel’s CSF firewall and ModSecurity guide covers network and web application security layers.

Linux Log Rotation Quick Reference

Frequently Asked Questions About Rotating Logs in Linux

Final Thoughts

Knowing how to rotate logs in Linux is an important part of server administration. logrotate provides a structured way to control log growth, retain useful historical data, compress older files, and prevent unnecessary storage consumption.

Start by understanding the existing configuration in /etc/logrotate.conf and /etc/logrotate.d/. Then create application-specific rules when needed, test them with debug mode, and monitor the resulting files.

Most importantly, do not treat log rotation as a simple delete operation. A good rotation policy balances storage, troubleshooting, security, and retention.

If you manage Linux servers regularly, make log rotation part of your routine server maintenance instead of waiting until a filesystem reaches 100% usage.