Context
Log rotation changes files; the application decides where its next write goes. A dependable procedure connects those two behaviors. Renaming a log, creating a replacement and compressing an archive can all succeed while the daemon has not switched its output to the intended current file.
Before adjusting rotation, identify the exact writer, package-supplied rotation rule, retention requirement and application-supported reopen method. Use a test service or a maintenance window for activation. Do not force rotation of every system log as an exploratory step. The aim is to prove one application's write contract with a harmless marker.
Inspect rule and writer together
- Read the specific file under
/etc/logrotate.d/and check whether the same path also appears in another rule. Reviewcreate, owner/group,su, compression timing and anypostrotateblock. If the stanza rotates several logs, examine whethersharedscriptsdeliberately runs the hook once for the whole stanza. Duplicate assumptions can produce surprising hook frequency. - Find the daemon's documented reopen mechanism. It may use a signal, a service-specific command or a supported reload action. Do not assume every daemon treats the same signal identically. Verify the service name and command path in the hook, and distinguish a reload that reopens logs from one that only reloads application settings.
- Use
logrotate --debug /etc/logrotate.d/exampleto inspect the target rule without performing rotation. Check local command support and include any relevant global settings in the review. A debug run explains decisions but cannot prove the daemon will reopen successfully, the resulting permissions will permit writing or the hook will work in the timer's environment.
An illustrative missing marker
In an illustrative order-processing service, the archive receives the first marker after rotation while the new current log stays empty. The rule renamed the file correctly, but its hook called an obsolete unit name. The service status remains healthy because normal processing continues. Correcting retention counts would not address this failed handoff between file rotation and the writer.
| Observation | Check | Correction boundary |
|---|---|---|
| New current file remains empty | Supported reopen command and hook result | Writer activation |
| New file exists but writes fail | create identity and parent access | New-file permissions |
| Hook executes repeatedly | Stanza paths and sharedscripts | Rotation grouping |
| Occasional records missing with truncation | copytruncate design and application support | Rotation method tradeoff |
Choose the supported rotation method
Prefer the application's documented approach. The logrotate manual describes copytruncate as copying the current file and then truncating it in place, with a possible data-loss interval. It can be necessary for programs that cannot reopen, but that tradeoff should be explicit. Do not choose it merely to avoid investigating a broken hook.
Change the relevant rule in configuration management, preserving the prior version and the state-file assumptions. Rehearse one controlled rotation with markers written before and after it. Verify their chronological placement, current-file ownership, hook exit status and subsequent compression behavior. Also confirm the application's ordinary operation remains healthy during the transition.
Keep rotation observable
Monitor the rotation timer or scheduled job, hook errors, current-file freshness and archive growth. The operating procedure should identify the writer, supported reopen action, retention owner and a safe manual test. Review it whenever packages or unit names change. Clouvenix Linux administration can help make rotation acceptance part of service maintenance rather than a filesystem-only task.
Technical reference
Upstream logrotate manual source and rendered logrotate manual.