Logrotate Production Mastery: Size Limits, Compression, Signals

Unchecked log files are among the most frequent causes of sudden disk full emergencies on production servers. When an application log exhausts storage, database engines trigger read-only emergency fallbacks, crash dumps fail to record, and system daemons terminate unpredictably. While logrotate is present on nearly every Linux distribution, naive default configurations frequently lose log lines during rotation or crash daemons due to improper signal handling.

Configuring logrotate for enterprise workloads requires mastering two core rotation mechanisms: the standard move-and-signal pattern (where the active file is renamed and the application receives a SIGHUP/SIGUSR1 to reopen its file descriptor), and copytruncate (used for legacy services that cannot reopen log handles).

Expand

High-Throughput Production Configuration

Here is an enterprise-ready logrotate configuration for an edge Nginx or reverse proxy service using modern Zstandard (zstd) compression:

# /etc/logrotate.d/production-proxy
/var/log/proxy/*.log {
    daily
    missingok
    rotate 14
    maxsize 500M
    compress
    compresscmd /usr/bin/zstd
    compressext .zst
    compressoptions -19 -T0
    delaycompress
    notifempty
    create 0640 www-data adm
    sharedscripts
    postrotate
        if [ -f /var/run/nginx.pid ]; then
            kill -USR1 $(cat /var/run/nginx.pid)
        fi
    endscript
}

Key parameters in this configuration include:

• maxsize 500M: Rotates immediately if the log exceeds 500MB, even if the daily cron has not yet elapsed.
• compresscmd /usr/bin/zstd: Replaces legacy gzip with Zstandard, yielding up to 3x higher compression ratios at 5x the speed.
• delaycompress: Delays compression until the subsequent rotation cycle, guaranteeing the active daemon has cleanly released the file descriptor.
• sharedscripts: Executes the postrotate script once across all matching logs rather than repeatedly per file.

Testing and Debugging Rotations

Never deploy a logrotate rule without testing its execution path. Use the -d (debug) flag to simulate the run without touching any files on disk:

# Dry run simulation with verbose evaluation output
sudo logrotate -d /etc/logrotate.d/production-proxy

# Force immediate execution to verify script execution and permissions
sudo logrotate -f /etc/logrotate.d/production-proxy

# Inspect the state file to review recorded rotation dates
cat /var/lib/logrotate/status | grep proxy

Automation and Scripting Video

Learn more about automating system maintenance tasks and Linux scripts in this overview:

Best Practices for Daemon Signals

When utilizing the postrotate block, always ensure the command returns exit code 0 even if the daemon is currently stopped. Using /bin/systemctl kill -s USR1 --kill-who=main proxy.service 2>/dev/null || true guarantees that transient service outages do not break the entire system-wide logrotate cron job.

Run reliable background jobs and log pipelines on rock-solid VPS infrastructure at netbayhosts.in.