How to Configure Logrotate for Custom Application Logs with Size-based Rotation, Compression, and Postrotate Hooks on Ubuntu Server

ByAkensai

Knowing how to configure logrotate for custom application logs with size-based rotation, compression, and postrotate hooks on Ubuntu Server is a skill every sysadmin needs. Without proper log management, your disk fills up fast. Applications slow down. Debugging becomes a nightmare. This tutorial walks you through creating a custom logrotate configuration from scratch. You’ll set up size-based rotation so logs rotate when they hit a specific file size. You’ll enable gzip compression to save disk space. You’ll also add postrotate hooks to signal your application after each rotation. By the end, your custom app logs will be managed automatically, reliably, and efficiently. This guide targets Ubuntu Server 20.04 and 22.04, but the steps work on most Debian-based systems.

Prerequisites for Configuring Logrotate on Ubuntu Server

Before you start, make sure you have the following in place.

Required access and software:

  • Ubuntu Server 20.04 or 22.04 (fresh or existing install)
  • A user account with sudo privileges
  • Logrotate installed (it ships with Ubuntu by default)
  • A running application that writes logs to a known path
  • Basic familiarity with the Linux command line and text editors like nano or vim

Estimated time: 20–30 minutes.

First, confirm logrotate is installed on your system:

logrotate --version

If it’s not installed, run:

sudo apt update && sudo apt install logrotate -y

You should also know where your application writes its logs. This tutorial uses /var/log/myapp/myapp.log as the example path. Replace this with your actual log path throughout. For reference on logrotate’s full option set, check the official logrotate man page.

How to Configure Logrotate with Size-based Rotation, Compression, and Postrotate Hooks

You might also find this useful: How to Deploy and Expose Applications on Kubernetes Using Deployments, Services, and Ingress

Follow these steps carefully. Each step builds on the last.

Step 1: Verify your application log path exists.

Before writing any configuration, confirm the log directory and file exist:

ls -lh /var/log/myapp/

If the directory doesn’t exist yet, create it and set the right permissions:

sudo mkdir -p /var/log/myapp
sudo chown myappuser:myappuser /var/log/myapp

Replace myappuser with the actual user your application runs as.

Step 2: Create a custom logrotate configuration file.

Logrotate reads drop-in config files from /etc/logrotate.d/. Create a new file for your application:

sudo nano /etc/logrotate.d/myapp

Step 3: Write the logrotate configuration block.

Paste the following configuration into the file:

/var/log/myapp/myapp.log {
    size 50M
    rotate 7
    compress
    delaycompress
    missingok
    notifempty
    copytruncate
    dateext
    dateformat -%Y%m%d-%H%M%S
    postrotate
        systemctl reload myapp > /dev/null 2>&1 || true
    endscript
}

Save and close the file with Ctrl+X, then Y, then Enter.

Here’s what each directive does:

  • size 50M , Rotate the log when it reaches 50 megabytes. Logrotate checks this on its next scheduled run.
  • rotate 7 , Keep 7 old log files before deleting the oldest one.
  • compress , Compress rotated logs using gzip.
  • delaycompress , Skip compression on the most recently rotated log. This prevents issues with apps still writing to it.
  • missingok , Don’t throw an error if the log file is missing.
  • notifempty , Don’t rotate the log if it’s empty.
  • copytruncate , Copy the log file, then truncate the original. Use this when your app can’t reopen its log file after rotation.
  • dateext / dateformat , Append a timestamp to rotated filenames for easier identification.
  • postrotate / endscript , Run a shell command after rotation. Here, it reloads the application service.

Step 4: Test the configuration for syntax errors.

Always test before relying on it in production:

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

The --debug flag runs logrotate in dry-run mode. It shows you what would happen without actually rotating anything. Look for errors in the output. A clean run shows something like:

reading config file /etc/logrotate.d/myapp
Handling 1 logs
rotating pattern: /var/log/myapp/myapp.log  50 megabytes (7 rotations)

Step 5: Force a manual rotation to verify everything works.

Once the debug output looks clean, force a real rotation:

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

Check the log directory to confirm the rotation happened:

ls -lh /var/log/myapp/

You should see a compressed, timestamped file alongside the fresh myapp.log.

Step 6: Confirm the postrotate hook fired correctly.

Check your application’s status after the forced rotation:

sudo systemctl status myapp

If the service reloaded cleanly, the postrotate hook is working. You can also check the system journal for reload events:

sudo journalctl -u myapp --since "5 minutes ago"

Step 7: Verify the logrotate cron job is active.

On Ubuntu, logrotate runs daily via a cron job at /etc/cron.daily/logrotate. Confirm it’s there:

ls -lh /etc/cron.daily/logrotate

Since you’re using size-based rotation, logrotate will check the file size each day. If your app generates logs quickly, consider running logrotate more frequently via cron. For example, add an hourly check by creating a cron entry:

sudo crontab -e

Add this line to run logrotate every hour:

0     /usr/sbin/logrotate /etc/logrotate.d/myapp

For more on scheduling tasks this way, see the Ubuntu CronHowto community guide.

Troubleshooting Common Logrotate Configuration Issues

Even a careful setup can hit snags. Here are the most common problems and how to fix them.

Problem: Logs aren’t rotating even though they’re large enough.
Check the logrotate state file at /var/lib/logrotate/status. If logrotate ran recently, it won’t run again until the next scheduled interval. Use --force to override this during testing.

Problem: The postrotate hook fails silently.
Add error logging to your postrotate block temporarily:

postrotate
    systemctl reload myapp >> /tmp/logrotate-debug.log 2>&1 || true
endscript

Check /tmp/logrotate-debug.log for error messages.

Problem: Rotated logs aren’t being compressed.
Remember that delaycompress skips compression on the most recent rotation. The file from the previous rotation will compress on the next run. This is expected behavior.

Problem: Application crashes after rotation.
If your app doesn’t handle copytruncate well, switch to using create mode instead. Remove copytruncate and add:

create 0640 myappuser myappuser

Then update your postrotate hook to send a signal that tells the app to reopen its log file. Many apps support SIGUSR1 for this:

postrotate
    kill -USR1 $(cat /var/run/myapp.pid) > /dev/null 2>&1 || true
endscript

Warning: Never use copytruncate with databases or apps that lock log files exclusively. Data loss can occur during the copy window.

Conclusion: Automating Log Management with Logrotate on Ubuntu

You now know how to configure logrotate for custom application logs with size-based rotation, compression, and postrot

Similar Posts