Configuring logrotate: copytruncate, postrotate and dry-run testing

Goal

Add or adjust a rotation rule for an application log file, choose the correct rotation strategy for how the application writes to it, and confirm the rule without waiting for the next scheduled run.

Prerequisites

Root access; the path to the log file and knowledge of whether the writing process holds the file open continuously or reopens it per write.

Steps

1. Create or edit a rule in its own file under /etc/logrotate.d/, e.g. /etc/logrotate.d/myapp:

   /var/log/myapp/*.log {
       weekly
       rotate 8
       compress
       missingok
       notifempty
       postrotate
           systemctl kill -s HUP myapp.service
       endscript
   }
   

2. Decide the rotation strategy. The default rename-and-recreate approach requires the writing process to reopen the file, normally triggered from postrotate by signalling it (as above) or reloading it. If the process cannot be told to reopen its log, use copytruncate instead: logrotate copies the current file, then truncates the original in place, so the process keeps its original file descriptor. copytruncate risks losing the few log lines written between the copy and the truncate; a postrotate signal to a process that supports reopening avoids that gap but depends on the process handling the signal correctly.
3. Preview the effect without changing anything: logrotate -d /etc/logrotate.d/myapp runs in debug/dry-run mode, printing what it would do (rotate, skip, or not — e.g. because notifempty suppressed an empty file) without writing to disk.
4. Force an out-of-schedule rotation for testing, ignoring the configured interval and last-rotation timestamp: logrotate -f /etc/logrotate.d/myapp. This is the standard way to validate a new rule immediately rather than waiting for the next weekly/daily cycle.
5. Verify: the old log is renamed/compressed as configured, the new file exists with the expected permissions from create (if used), and, for a postrotate signal, the application's process still writes to the new file (lsof <pid> showing the new inode, or fresh log lines appearing).

Expected result

logrotate -d shows the intended actions with no errors; a forced run with -f produces the rotated file, and the application continues logging without an unbounded old file handle.

Limits and test basis

Based on logrotate(8) and logrotate.conf(5). To undo a bad rule, edit or remove the file under /etc/logrotate.d/; logrotate keeps its own state in a status file (commonly /var/lib/logrotate/status), so a forced test run still updates the last-rotated timestamp there. Back up that status file before repeated -f testing if the production rotation count (rotate N) must not be disturbed.