Logrotate

What Logrotate Does in Operational Logging

Logrotate is not a logging system itself, it is a housekeeping utility for existing logs. Its job is to keep log files manageable by rolling them over on schedule, compressing older copies, and removing data that has aged beyond the retention policy.

That makes it especially useful in environments where services write continuously to the same file. Without rotation, log growth can become an availability problem as disks fill, writes slow, or applications lose the ability to create new records.

How Rotation Works in Practice

A rotation cycle usually renames the active file, creates a fresh one, and then applies any configured post-rotation action so the application continues writing to the new target. Some deployments rely on signal handling or service reloads so the writer closes and reopens its file descriptor cleanly.

Because rotation changes filenames and file handles, the utility has to coordinate with the application’s logging behaviour. A daemon that does not reopen logs correctly may keep writing to the old file, which defeats the purpose of rotation and can make operations teams think logging has stopped when it has not.

Logrotate can also compress archived logs and enforce retention windows, which helps balance audit needs against storage cost. The practical trade-off is that aggressive cleanup reduces disk pressure but may shorten the window available for investigations, compliance checks, or performance analysis.

Why Log Rotation Matters for Security Operations

From a security perspective, rotation is a visibility control as much as a storage control. Logs that are kept too long without organisation become harder to search, while logs that are deleted too quickly can leave investigators without evidence after an incident.

Good rotation design also reduces the chance that logging itself becomes a failure point. If an attacker or faulty process causes rapid log generation, an unmanaged log directory can contribute to service disruption, hide malicious activity in noise, or force emergency cleanup under pressure.

Used well, the Log Management and Retention Guide helps place rotation in the broader context of retention, archival tiers, and log integrity rather than treating it as a standalone cron job.

Common Failure Modes and Operational Boundaries

Logrotate works best when file naming, ownership, permissions, and retention rules match the way the application actually writes logs. Misalignment there can produce empty archives, missing records, duplicate rotations, or files that rotate successfully but are never consumed by downstream monitoring.

It is also important to distinguish rotation from full log governance. Rotation manages file lifecycle, but it does not by itself guarantee central collection, integrity protection, tamper resistance, or review processes. Those controls have to be layered around it if logs are to remain useful as evidence.

When retention is driven by policy, the utility should be configured to support that policy rather than replace it. The rotation schedule, compression choice, and deletion threshold should reflect how long the logs must remain available for analysis and accountability.