Identify the exact log path, owner, average growth and required retention. Confirm the application's documented log-reopen behavior and preserve any logs needed for an active incident. Do not rotate a database data file or a file already managed by another policy.

1. Create a dedicated configuration under the distribution's logrotate include directory. Scope the path narrowly to the intended application logs.
2. Choose time/size thresholds, retained count and compression according to actual growth. Specify ownership and creation mode so the application can continue writing without broad permissions.
3. Use the application-supported reopen action in the rotation hook when required. Review whether delayed compression is needed while the process transitions to its new file.
4. Treat copytruncate as a compromise only when reopening is impossible and its data-loss window is understood. Do not assume it is equivalent to an atomic application-aware rotation.
5. Validate with logrotate debug mode, which reports intended actions without rotating. Then perform one controlled rotation during a suitable window and inspect the result.
6. Confirm the scheduled system timer or cron mechanism will process the policy and monitor subsequent rotations.

After drafting a dedicated logrotate configuration, test the installed configuration in debug mode from an authorised Linux shell. Replace the example filename with your actual rule. Debug mode evaluates the policy without rotating logs or updating the logrotate state file.

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

Read the result: Review the selected log paths, rotation decision, retention, compression and any postrotate script. A successful parse does not prove that the application will reopen its log correctly. A file that remains open under its old name can keep growing after rotation unless the service supports the configured reopen action.

Test the complete lifecycle during an approved maintenance period before relying on the schedule. Match the ownership and permissions to the application account, and keep diagnostic output private if paths reveal tenant information. Avoid forcing a rotation merely to silence a parse error.

No. Rotation limits local retention. If longer investigation or audit retention is required, forward or copy logs to a protected independent destination under a defined policy.

Check that the application writes new entries into the active file, retained files have expected ownership and compression, and disk use follows policy. Confirm no deleted open log remains consuming space.

For permission errors, inspect parent-directory ownership and the appropriate user/group context rather than making logs world-writable. For missing entries, review the reopen hook and copytruncate race. Avoid force-rotating repeatedly because it can consume the configured retention quickly and remove useful history.

• Recovering service when a Linux filesystem is full
• Finding deleted files that still consume disk space
• Running a maintenance job with a systemd timer
• Diagnosing a Linux server with no free inodes

• Debian manual: Logrotate.8.en
• Debian manual: Lsof.8.en