Linux logrotate manages rotation, compression, and removal of selected log files according to configuration and invocation. It helps control local storage, but moving a filename does not automatically make the application write to the new file. Correct rotation requires coordination with the process that owns the open log descriptor.
A reliable setup defines both retention and writer handoff. This guide explains rename behavior, copytruncate tradeoffs, scheduling, permissions, and verification so a tidy directory listing does not conceal lost events or an application still writing into an old archive.
Inventory the log and its actual writer
Identify the process, path, ownership, and logging method. File logging, systemd journal logging, and container-managed logging have different lifecycle controls. Do not apply a generic file-rotation rule to a system whose logs are managed elsewhere.
Check whether the application holds an open descriptor and how it supports reopening. Renaming the path normally does not force that descriptor to point at a newly created file. The writer’s documented behavior is central to the design.
Record the retention purpose: troubleshooting, audit evidence, or another requirement. Those purposes can need different completeness and access guarantees. Space management should not silently erase required incident evidence.
Choose rename and reopen where supported
A common rotation workflow renames the current file, creates a new one, and tells the application to reopen its log through a supported action. Verify the action and signal in the application’s documentation.
Do not send a guessed signal to a production process. Signals can mean reload, termination, or something else. A postrotate command should be scoped to the intended writer and tested with the actual service identity.
Confirm that new entries appear in the new file after rotation. Inspect the writer’s behavior, not only the creation of an empty replacement. The old archive can continue growing if handoff failed.
Understand the copytruncate loss window
Copytruncate copies the existing file and then truncates it in place. It can help with applications that cannot reopen their log, but the copy-and-truncate interval can lose entries written between those operations.
Do not call this method lossless. Decide whether that risk is acceptable for the specific log purpose. For required audit evidence, a different logging or handoff design may be necessary.
Consider file size and write rate in testing. A quiet small file understates the risk and resource cost of copying a large active log. Review supported options and their interactions rather than combining them blindly.
Set permissions for both live and rotated files
A newly created log needs appropriate owner, group, and mode so the application can continue writing without making private events broadly readable. Test using the runtime identity rather than only an administrator account.
Review parent-directory ownership and permissions. Rotation often runs with elevated authority, so writable or untrusted paths can introduce risks. Use the supported configuration for the intended ownership model.
Protect compressed archives too. Compression saves space but does not encrypt content or change its sensitivity. Logs can contain personal information, identifiers, or accidentally recorded credentials throughout their retention period.
Match rotation rules to invocation frequency
Logrotate evaluates rules when it runs. A size threshold is not continuously enforced merely because it appears in configuration. If the scheduler invokes rotation infrequently, the file can grow beyond the threshold before the next check.
Review time-based and size-based options and their documented interactions for the installed version. A combination that sounds intuitive may not implement the expected policy. Test the effective configuration.
Confirm the system’s scheduler actually invokes the intended configuration. Distribution defaults, timers, and local overrides vary. A correct rule in an unused file provides no protection against storage growth.
Keep retention and capacity distinct
A rotation count describes retained generations under the chosen rule; it does not necessarily equal a fixed number of calendar days. Variable write rates and rotation frequency change how much time those files represent.
Set disk-capacity monitoring separately. Compression ratio, delayed compression, and archive location can affect footprint. Retention configuration should not be the only warning before a shared filesystem fills.
Review backups and central log shipping. Removing a local archive does not necessarily remove remote copies, while successful shipping should be verified before relying on it for evidence. State each storage system’s responsibility.
Validate safely before forcing changes
Use the installed version’s documented debug or validation behavior to inspect what would happen without changing files where supported. Then test actual rotation in a controlled environment with representative ownership and write activity.
Do not force rotation in production simply to see whether the command succeeds. Forced behavior can remove or replace evidence and trigger postrotate actions. Obtain the appropriate operational approval and recovery plan.
Inspect the state file and failure output through the supported workflow. Avoid overlapping unmanaged invocations that can conflict or hide errors. A scheduler’s successful start does not prove rotation finished correctly.
Verify events across the boundary
Generate controlled identifiable test events before, during, and after rotation. Confirm they appear in the expected files and that the application keeps writing. Include a failed reopen or permission-denied test where appropriate.
Check archive readability, compression timing, and eventual removal under the approved retention rule. Preserve nonsecret evidence of the test rather than copying sensitive production log content into an unrestricted report.
For a file-writing web service, use its documented reopen path, restrictive new-file permissions, and a scheduler frequent enough for expected growth. Monitoring then detects handoff failure or capacity pressure instead of assuming rotation is self-verifying.
Keep postrotate failures visible
A postrotate action can fail even when a file was renamed or copied successfully. Monitor the complete invocation and application behavior so partial success does not disappear behind an apparently tidy archive.
Decide what the operator should do if reopening fails: restore the intended path, use a supported service action, or escalate according to policy. Do not repeatedly force rotation while the writer still holds the old descriptor. That can complicate evidence and storage state further.
Frequently asked questions
Does renaming a log redirect an open writer?
Not automatically. The application needs a supported reopen or another appropriate logging design.
Is copytruncate lossless?
No. Events can be lost in the copy-and-truncate window.
Where should I check supported options?
Read the installed logrotate manual and the upstream logrotate project for version-specific configuration behavior.
For a complementary workflow, read Systemd Journal Retention: Keep Useful Evidence Without Exhausting Storage.
