Preventing Server Crashes with Automated Log Rotation (logrotate)

While system logs are absolutely essential for diagnosing errors and feeding security tools like Fail2Ban or Logwatch, they also represent a significant stability risk. Every time a user visits your website, an SSH connection fails, or a database query executes, data is written to your server’s hard drive. Under heavy traffic or during a targeted DDoS attack, these text files can rapidly balloon to gigabytes in size.

If your VPS runs out of disk space, the consequences are catastrophic. Databases will immediately crash and corrupt, background services will fail to start, and you may even be locked out of SSH entirely. To ensure server availability (a core pillar of security), you must actively manage log file growth using a built-in Linux utility called logrotate.

Understanding the Logrotate Daemon

logrotate is a background utility designed to automatically archive, compress, and eventually delete old log files before they consume your entire storage drive.

Instead of forcing your applications to manage their own file sizes, logrotate runs as a daily cron job. It checks your configured rules and takes action—such as renaming yesterday's access.log to access.log.1, compressing it into a tiny archive, and creating a fresh, empty access.log for your web server to continue writing to without interruption.

The Configuration Hierarchy

Linux distributions organize log rotation configurations into a strict hierarchy to keep system logs and application logs separate.

• Global Settings: The primary configuration file is located at /etc/logrotate.conf. This defines the default behavior for the entire server (e.g., rotating files weekly and keeping four weeks of history).

• Service-Specific Rules: Individual applications (like Nginx, Apache, MySQL, and UFW) drop their own custom rules inside the /etc/logrotate.d/ directory. When the daemon runs, it reads the global configuration first, then applies these specific overrides.

Creating a Rule for Custom Applications

If you are hosting a custom application (like a Node.js backend, a Python Flask API, or a Docker container) that writes logs to a specific folder, those files will grow infinitely unless you explicitly tell logrotate to manage them.

• Connect to your server via SSH and create a new configuration file in the specific directory: sudo nano /etc/logrotate.d/my_custom_app

• Add a configuration block defining exactly how the logs should be handled. A highly robust configuration looks like this:

/var/www/mywebsite/logs/*.log {
    daily
    rotate 14
    size 50M
    compress
    delaycompress
    missingok
    notifempty
    create 0640 www-data www-data
    postrotate
        systemctl reload my_custom_app > /dev/null 2>&1 || true
    endscript
}

Breaking Down the Directives

Understanding exactly what these commands do ensures you don't accidentally delete active logs or break your application's file permissions.

• daily / rotate 14: Instructs the daemon to rotate the logs every single day and keep exactly 14 days of history before permanently deleting the oldest archive.

• size 50M: Acts as a safety trigger. Even if a day hasn't passed, the log will immediately rotate if it exceeds 50 Megabytes (crucial during an active DDoS attack).

• compress / delaycompress: Archives the old logs using gzip to save disk space. delaycompress waits one extra cycle before compressing, ensuring the application has completely finished writing to the old file before it is zipped.

• missingok / notifempty: Prevents the cron job from throwing an error if the log file was deleted, and skips rotation entirely if the log file is currently empty.

• create 0640 www-data www-data: When the fresh log file is created, this instantly applies strict file permissions and assigns ownership to your web server user, preventing unauthorized users from reading the application output.

• postrotate: Many applications hold onto file handles indefinitely. This block allows you to execute a bash command (like gracefully reloading the app) immediately after rotation, forcing the application to let go of the old file and begin writing to the new one.

Testing Your Configuration

Before relying on your new rule to prevent a server crash, you should test it to ensure the syntax is correct and the permissions are valid.

• Run logrotate in debug (dry-run) mode by executing: sudo logrotate -d /etc/logrotate.d/my_custom_app

• The terminal will output a detailed, step-by-step log of exactly what the daemon would do, without actually modifying or deleting any of your files. Review this output to confirm it is targeting the correct files and applying the correct ownership constraints.