Manual Execution of Logrotate: Principles, Methods and Best Practices

Logrotate Manual Execution Mechanism

In Linux system administration, logrotate serves as the standard log rotation tool, typically executed through cron or systemd scheduling. However, in practical operations scenarios, there is often a need to manually trigger log rotation operations. According to the best answer in the Q&A data, using the logrotate --force $CONFIG_FILE command can force immediate execution of one log rotation cycle, regardless of whether the log files meet the preset rotation conditions.

Core Parameter Deep Analysis

The --force parameter is key to manual execution, and its working mechanism involves judgment logic at multiple levels. When logrotate runs normally, it checks conditions such as log file size and modification time, only performing rotation when the thresholds set in the configuration file are met. The --force parameter bypasses these checks and forces immediate rotation.

From an implementation perspective, logrotate internally maintains a state machine that records the rotation history of each log file. The --force parameter resets this state machine, making the system believe that all log files require immediate rotation. This mechanism is particularly useful in the following scenarios:

# Example configuration: /etc/logrotate.d/myapp
/var/log/myapp/*.log {
    daily
    rotate 7
    compress
    delaycompress
    missingok
    notifempty
    create 644 root root
}

Application of Debug Mode

In addition to forced rotation, the Q&A data also mentions the use of debug mode. The logrotate -d [your_config_file] command performs a simulated execution before actual rotation, outputting detailed debug information without making any changes to the log files. This mode is valuable for verifying configuration file correctness and troubleshooting rotation issues.

The debug mode output includes a complete execution plan:

# Debug mode output example
reading config file /etc/logrotate.d/myapp
Handling 1 logs
rotating pattern: /var/log/myapp/*.log  after 1 days (7 rotations)
empty log files are not rotated, old logs are removed
considering log /var/log/myapp/access.log
  log needs rotating

Deployment Strategies in Container Environments

Reference Article 1 discusses in depth the challenges and solutions of using logrotate in containerized environments. Traditionally, logrotate relies on system-level scheduling mechanisms (such as cron or systemd), but in container environments, these mechanisms may be unavailable or complex to configure.

An effective solution is to adopt a centralized log management architecture:

# Centralized log rotation configuration example
/data/logs/*/*.log {
    daily
    rotate 30
    compress
    copytruncate
    missingok
    size 100M
}

In this architecture, all containers write logs to shared storage volumes, managed uniformly by a dedicated log rotation container. This approach not only simplifies configuration maintenance but also enhances system observability.

Permissions and Configuration Verification

Reference Article 2 emphasizes the importance of permission configuration. Logrotate typically runs as the root user and requires sufficient read/write permissions for target log files. Especially in container environments, permission settings for mounted volumes need careful examination.

Configuration verification is another critical aspect. Testing through manual execution can promptly identify configuration issues:

# Permission check script example
#!/bin/bash
LOGFILE="/var/log/myapp/application.log"
CONFIG_FILE="/etc/logrotate.d/myapp"

# Check file permissions
ls -la $LOGFILE
# Check configuration syntax
logrotate -d $CONFIG_FILE
# Test execution
logrotate --force $CONFIG_FILE

Advanced Application Scenarios

In complex production environments, manual execution of logrotate often requires coordination with other system components. For example, after rotation, it may be necessary to reload service configurations or send notifications:

# Configuration with post-processing operations
/var/log/nginx/*.log {
    daily
    rotate 14
    compress
    postrotate
        /usr/bin/systemctl reload nginx
        /usr/local/bin/send_rotation_notification.sh
    endscript
}

This integrated approach ensures coordinated operation between log rotation and other system components, preventing service abnormalities caused by rotated log files.

Troubleshooting and Best Practices

Based on experiences from the reference articles, the following best practices are summarized: First, always use debug mode to verify after configuration changes; second, ensure the rotation container has appropriate permissions for shared storage; finally, establish comprehensive monitoring mechanisms to promptly detect rotation failures.

For common permission issues, diagnosis can be performed through the following methods:

# Permission diagnostic commands
# Check file ownership
ls -la /var/log/
# Check SELinux context (if applicable)
ls -Z /var/log/
# Test manual execution
sudo logrotate --force /etc/logrotate.conf

Through systematic methods and rigorous verification processes, stable operation of logrotate can be ensured across various environments.