html

As a sysadmin, you'll often need to test new logrotate configurations before deploying them in production. The common scenarios include:

• Adding new log files to rotate
• Modifying rotation frequency or compression settings
• Testing post-rotation scripts

The most reliable way to test your new configuration is using the -d (debug) and -f (force) flags:

sudo logrotate -v -d -f /etc/logrotate.conf

Key flags explanation:

-v: Verbose output

-d: Debug mode (dry run)

-f: Force rotation even if not scheduled

To test just one configuration file from /etc/logrotate.d/:

sudo logrotate -v -d -f /etc/logrotate.d/your_app

When you're ready to actually rotate logs (remove -d for real execution):

sudo logrotate -v -f /etc/logrotate.d/your_app

Check the results with these commands:

ls -lh /var/log/your_app*
cat /var/lib/logrotate/status

For a new Nginx configuration at /etc/logrotate.d/nginx:

/var/log/nginx/*.log {
    daily
    missingok
    rotate 14
    compress
    delaycompress
    notifempty
    create 0640 www-data adm
    sharedscripts
    postrotate
        /etc/init.d/nginx reload > /dev/null
    endscript
}

Test with:

sudo touch /var/log/nginx/access.log
sudo logrotate -v -d -f /etc/logrotate.d/nginx

• Check /var/lib/logrotate/status for last rotation dates
• Test as root or with sudo to avoid permission issues
• Set correct file permissions on log files before testing
• Use absolute paths in configuration files

---

Creating new configuration files in /etc/logrotate.d/ is common for custom log management, but waiting for the daily cron job isn't practical during development or troubleshooting. Manual execution lets you:

• Validate syntax errors immediately
• Test rotation conditions without waiting
• Verify permissions and paths
• Check post-rotation commands

The standard syntax for forced execution:

sudo logrotate -vf /etc/logrotate.conf

Flags explanation:

-v : verbose output
-f : force rotation regardless of schedule

To test just your new configuration (example for nginx):

sudo logrotate -vf /etc/logrotate.d/nginx

Before actual rotation, use debug mode:

sudo logrotate -d /etc/logrotate.d/your_config

This shows what would happen without making changes.

For complex setups with multiple dependencies:

sudo logrotate -vf --debug /etc/logrotate.conf

This provides detailed processing information including:

• Configuration file parsing
• Log file state checks
• Rotation decision logic

When testing fails, check:

# Permission issues often surface first
sudo ls -l /var/log/your_service.log

# Verify file exists where expected
sudo test -f /var/log/your_service.log && echo "Exists"

Sample debug output for a custom app:

reading config file /etc/logrotate.d/custom_app
Considering log /var/log/custom_app/*.log
  Now: 2023-11-15 10:00
  Last rotated at 2023-11-14 09:00
  log needs rotating
rotating log /var/log/custom_app/access.log, log->rotateCount is 4
dateext suffix '-20231115'
glob pattern '-[0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9]'
glob finding logs to compress failed
glob finding old rotated logs failed
renaming /var/log/custom_app/access.log to /var/log/custom_app/access.log-20231115
creating new /var/log/custom_app/access.log mode = 0644 uid = 1000 gid = 1000
running postrotate script

• Always back up logs before forced rotation
• Monitor disk space during testing
• Verify cron will pick up your changes (sudo cat /etc/cron.daily/logrotate)
• Check system logs if rotation fails (journalctl -u logrotate)