To set up logrotate for custom log files on a Linux server, create a configuration file in /etc/logrotate.d/, define rotation rules, test the setup, and handle apps that don’t reopen logs. 1. Create a config file like /etc/logrotate.d/myapp with rules such as daily, rotate, compress, delaycompress, missingok, notifempty, and create. 2. Test syntax with logrotate -d and force a dry run with logrotate -f. 3. For apps that don’t automatically reopen logs, add a postrotate script using kill -USR1 or systemctl reload to restart the service and ensure logging continues properly.

If you're managing a Linux server and have custom log files from your applications, setting up logrotate is essential. It helps keep logs under control by rotating, compressing, and deleting them automatically. Here’s how to do it right for your own log files.

Create a Custom Logrotate Configuration File

Instead of editing the main /etc/logrotate.conf, it's better to create a separate file in /etc/logrotate.d/. This keeps things clean and easy to manage.

For example, if your app writes logs to /var/log/myapp.log, create a file like this:

sudo nano /etc/logrotate.d/myapp

Inside that file, define the rotation rules. A basic setup might look like:

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

Each line here sets a rule:

• daily means it rotates every day.
• rotate 7 keeps seven old logs before deleting older ones.
• compress compresses rotated logs.
• delaycompress delays compression until next rotation (good if you need uncompressed logs for analysis shortly after rotation).
• missingok prevents errors if the log file is missing.
• notifempty skips rotation if the log is empty.
• create sets permissions and ownership for the new log file.

Test Your Logrotate Configuration

After setting up or changing the config, test it to make sure there are no syntax errors.

Run:

logrotate -d /etc/logrotate.d/myapp

The -d flag runs it in debug mode, showing what it would do without actually making changes.

If everything looks good, force a dry run with:

logrotate -f /etc/logrotate.d/myapp

This forces a rotation and shows any real-time issues.

Note: If your app doesn't automatically write to a new log file after rotation, you may need to add a postrotate script to reload or restart the service.

Handle Applications That Don’t Automatically Reopen Logs

Some apps don’t notice when their log file has been moved or replaced. In those cases, you can use postrotate to send a signal so they reopen the log.

Update your config like this:

/var/log/myapp.log {
    daily
    rotate 7
    compress
    delaycompress
    notifempty
    create 640 root adm
    postrotate
        /bin/kill -USR1 $(cat /var/run/myapp.pid 2>/dev/null) 2>/dev/null || true
    endscript
}

This sends a USR1 signal to your app, telling it to reopen its log files. Replace /var/run/myapp.pid with the actual path to your app’s PID file.

If your app uses systemd, you might prefer to restart it:

postrotate
    systemctl reload myapp.service
endscript

Make sure to test after adding this part to avoid breaking log writing.

That's basically all you need to set up logrotate for your own log files. It's straightforward once you know which options matter most — and it makes log management way easier in the long run.

The above is the detailed content of How to configure logrotate for custom log files?. For more information, please follow other related articles on the PHP Chinese website!