Log Rotation: How It Works, Rotation Strategies, and Configuration for Mobile Projects

What Is Log Rotation

Log Rotation is the process of periodically switching the active log file to a new one while simultaneously archiving, compressing, or deleting the old one. Without rotation, a single log file grows indefinitely until it fills the entire disk partition, leading to application failure and data loss.

A typical scenario: an application writes logs to the app.log file. When app.log reaches 100 MB, the system renames it to app.log.1, compresses it to app.log.1.gz, and creates a new empty app.log. On the next fill-up, app.log.1 becomes app.log.2, app.log.1.gz becomes app.log.2.gz, and the old app.log.2.gz is deleted. This mechanism is called rotation with keep count — the number of archive copies is fixed.

According to Splunk (2023), incorrect rotation configuration is the cause of 40% of incidents related to disk space exhaustion on application servers. For mobile devices, rotation is even more critical because users cannot and should not manage logs manually.

Log Rotation Strategies

Log Rotation supports three basic strategies that can be combined. The choice of strategy depends on the application type: server systems more often use time-based rotation, mobile use size-based, and embedded systems use file-count-based.

Size-based rotation — the most common

Size-based rotation ensures that no single log file exceeds a set limit. The limit is chosen based on available disk space and logging frequency. For a server, the typical limit is 100–500 MB per file, for a mobile device — 1–10 MB. If the application logs aggressively, the limit should be lowered, otherwise rotation will occur every few minutes.

Time-based rotation — for compliance

Time-based rotation is independent of log volume — the file is switched strictly on schedule. Convenient for systems where logs must be stored for a fixed number of days: daily rotation with keep count = 30 means 30 days of storage. The downside — a single file can grow to a gigabyte per day under heavy load.

logrotate on Linux: Configuration and Examples

logrotate is the standard Linux utility for automatic log rotation. It runs via cron and processes configuration files from /etc/logrotate.d/. Each service (nginx, postgresql, application) creates its own config specifying log paths, rotation strategy, and post-rotation actions.

# /etc/logrotate.d/myapp — application log rotation
/var/log/myapp/*.log {
    daily
    rotate 7
    compress
    delaycompress
    missingok
    notifempty
    create 0640 www-data www-data
    postrotate
        kill -HUP $(cat /var/run/myapp.pid)
    endscript
}

This config rotates logs daily, keeps 7 archive copies, compresses old files with gzip (except the last one — delaycompress), does not error if logs are missing (missingok), does not rotate empty files (notifempty), and recreates the file with 0640 permissions. After rotation, it sends a HUP signal to the application process via a postrotate script.

logrotate Parameters

size — rotation upon reaching a size (size 100M). rotate — number of archive copies (rotate 7). compress — gzip compression. dateext — appends the date to the filename instead of a sequence number. sharedscripts — runs postrotate once for all files, not for each individually. maxage — deletes archives older than N days.

Log Rotation in Mobile Applications

On mobile devices, Log Rotation is critical because the user does not manage the file system and does not expect the application to take up gigabytes with logs. iOS and Android have built-in mechanisms: os_log on iOS uses a fixed-size ring buffer (rotation by overwrite), Android Logcat has a limited kernel buffer.

For custom file logs on iOS, CocoaLumberjack is used with the DDFileLogger class, which supports size-based and time-based rotation. On Android — Logback or custom implementations via RollingFileAppender. Both tools allow setting maximum file size and number of archives.

// CocoaLumberjack — file rotation on iOS
import CocoaLumberjack

let fileLogger = DDFileLogger()
fileLogger.maximumFileSize = 1024 * 1024 // 1 MB
fileLogger.logFileManager.maximumNumberOfLogFiles = 5
DDLog.add(fileLogger)

iOS: os_log does not require rotation — messages are overwritten in the ring buffer. But if the application writes custom file logs (for debugging or server upload), rotation must be configured manually. CocoaLumberjack is the standard choice for iOS teams — it automatically compresses archives to .gz and deletes old files when the limit is exceeded.

Why Rotation Matters on Android

Android does not restrict applications from writing logs to their own directory. If a developer writes debug logs to a file without rotation, over a month of active use they can take up 500 MB to 1 GB. The user will discover the problem when the system shows a low-storage warning and will delete the app. Logback with RollingFileAppender solves this problem: a 5 MB limit with 3 archives guarantees logs never exceed 20 MB.

Rotation Implementation Examples on iOS and Android

Below are examples of log rotation configuration on both platforms. On iOS, CocoaLumberjack is used; on Android — Logback with XML configuration.

// Logback on Android — rotation configuration in logback.xml
// File size 5MB, 3 archive copies
@file:Suppress("unused")

// In logback.xml:
// <appender name="FILE" class="ch.qos.logback.core.rolling.RollingFileAppender">
//   <file>${DATA_DIR}/logs/app.log</file>
//   <rollingPolicy class="ch.qos.logback.core.rolling.FixedWindowRollingPolicy">
//     <fileNamePattern>app.%i.log.gz</fileNamePattern>
//     <minIndex>1</minIndex>
//     <maxIndex>3</maxIndex>
//   </rollingPolicy>
//   <triggeringPolicy class="ch.qos.logback.core.rolling.SizeBasedTriggeringPolicy">
//     <maxFileSize>5MB</maxFileSize>
//   </triggeringPolicy>
// </appender>

CocoaLumberjack on iOS supports not only size-based rotation but also deletion of old logs by date using logFileManager.maximumLogFiles. If maximumLogFiles = 0 is set, the limit is removed — logs will accumulate indefinitely, which is dangerous for production.

// Custom rotation with total volume check
class SizeAwareLogger {
    let maxTotalSize: Int64 = 20 * 1024 * 1024

    func enforceQuota(at logDirectory: URL) {
        let files = (try? FileManager.default
            .contentsOfDirectory(
                at: logDirectory,
                includingPropertiesForKeys: [.fileSize]
            )) ?? []
        let total = files.reduce(0) {
            $0 + (try? $1.resourceValues(forKeys: [.fileSize])
                .fileSize).map(Int64.init) ?? 0
        }
        if total > maxTotalSize {
            // Delete the oldest file
            files.sorted { $0.path < $1.path }.first.map {
                try? FileManager.default.removeItem(at: $0)
            }
        }
    }
}

Monitoring and Alerts for Rotation

Log Rotation is not only about automatic archiving but also a health indicator. If logs rotate too frequently (every few minutes), it signals excessive logging or an error log loop. Set up alerts for rotation frequency: more than 10 rotations per hour warrants investigation.

Monitoring systems (Prometheus, Grafana, Datadog) can track rotation metrics through file system exporters. Prometheus node_exporter provides file size and modification time metrics. On mobile devices, rotation monitoring is usually built into the SDK: CocoaLumberjack logs the rotation event via DDLog, and Logback sends status through an appender.

Alerts: if there are more archives than expected (rotate count exceeded the limit) or the total log volume exceeds the quota — the system should notify the administrator. For servers, the standard threshold is 80% of the partition size; for mobile devices — an alert when 50 MB per application is exceeded.