logrotate failed: causes and fixes

What the "logrotate failed" Error Means

The logrotate failed error is a general notification from the task scheduling system (usually cron or systemd timer) that the logrotate log rotation service terminated with an error. This is not a specific error code, but rather the process exit status. The actual cause of the error is never indicated in this message. You need to look for it in the logs of logrotate itself.

Typical output in the system log (/var/log/syslog or via journalctl) might look like this:

error: error rotating /var/log/nginx/access.log: cannot open '/var/log/nginx/access.log' for reading: Permission denied

Or:

error: error creating new /var/log/nginx/access.log.1.gz (is filesystem full?): No space left on device

The logrotate configuration is usually run daily via the logrotate.timer systemd timer or a job in /etc/cron.daily/. The error means that log rotation did not occur, and old logs continue to grow, which can lead to disk space exhaustion.

Common Causes

The logrotate failed error is a symptom. Here are the most frequent root causes:

1. Insufficient Permissions (Permission denied). The user under which logrotate runs (usually root) lacks permission to read the source log file, write to the archive directory, or create a new (compressed) file. Often occurs if logs are created by another user (e.g., www-data for a web server) and have overly restrictive permissions.
2. Insufficient Disk Space (No space left on device). The partition where the source logs are stored or where compressed archives (.gz) should be saved has run out of free space. logrotate cannot create a new file or compress the old one.
3. Incorrect File Path in Configuration. The configuration files in /etc/logrotate.d/ specify a non-existent path to a log file or directory.
4. Conflicting or Syntactically Incorrect Configs. An error in one of the files in /etc/logrotate.d/ (e.g., a missing closing curly brace }) can cause the entire process to fail.
5. Log File Locked by Another Process. The application (nginx, Apache) or another process holds the file in an exclusive lock, and logrotate cannot rename it (which is the first step of rotation).
6. Compression Utility (gzip) Problem. If compression is enabled (compress or delaycompress) in the config, but the gzip utility is missing or corrupted, rotation will fail.
7. Error in postrotate/prerotate Script. If custom scripts are specified in the configuration, their execution may fail, causing the entire job to fail.

Solutions

Method 1: Analyze the Exact Error Message (Mandatory First Step)

Before fixing anything, you must find the true cause of the error.

1. Check the systemd journal (if using systemd-timer):

   sudo journalctl -u logrotate.service --since "1 hour ago" | grep -i error
   

   
   Or simply view the entire service log:

   sudo journalctl -u logrotate.service -n 50
   

2. Check the system log (if using cron.daily):

   sudo grep -i "logrotate" /var/log/syslog | tail -n 50
   

   
   Or, on CentOS/RHEL:

   sudo grep -i "logrotate" /var/log/messages | tail -n 50
   

3. Find lines containing error:. These contain the problem description (e.g., Permission denied, No space left on device, error: ...).

Method 2: Check and Correct Permissions

If you see Permission denied in the logs:

1. Determine which user/group the process runs as. Usually it's root.
2. Check the ownership and permissions on the problematic log file and its parent directory:

   ls -la /var/log/nginx/access.log
   ls -ld /var/log/nginx/
   

3. Option A (Recommended): Change the log file's group to the group the application runs as (e.g., www-data), and grant the group write permission. Then ensure logrotate (running as root) can read the file.

   sudo chown root:www-data /var/log/nginx/access.log
   sudo chmod 640 /var/log/nginx/access.log
   

   
   Ensure the /var/log/nginx/ directory is executable (+x) for root.
4. Option B (Less Secure): Temporarily grant full permissions for diagnosis (do not leave it like this!):

   sudo chmod 666 /var/log/nginx/access.log
   

   
   After fixing the issue, restore secure permissions.

Method 3: Free Up Disk Space

If the cause is No space left on device:

1. Check disk usage:

   df -h
   

   Find the filled partition (e.g., /var or /).
2. Manually clean up old or unnecessary logs (carefully!):

   # View largest files in /var/log
   sudo du -sh /var/log/* | sort -rh | head -n 10
   # Clean up old compressed logs (example for nginx)
   sudo rm -f /var/log/nginx/*.gz
   

   Caution: Do not delete active (current) log files without a dot (e.g., access.log). Only delete archives (*.gz, *.1, etc.).
3. After cleanup, run logrotate manually to check if it works:

   sudo logrotate -f /etc/logrotate.conf
   

Method 4: Check and Test Configuration

1. Check the syntax of all configs:

   sudo logrotate -d /etc/logrotate.conf
   

   The -d flag enables debug mode. The rotation logic will be run, but no files will actually be renamed, deleted, or compressed. This is safe.
2. Carefully review the output. Look for reading config file lines (ensure all needed files from /etc/logrotate.d/ are read) and error:. A common error is a missing closing } in one of the files.
3. If you find a problematic config in /etc/logrotate.d/, edit it. For a service like app:

   sudo nano /etc/logrotate.d/app
   

   Ensure the log paths exist:

   sudo ls -la /var/log/app/
   

Method 5: Resolve File Locking Issues

If an application (like nginx) holds the file open, logrotate may fail to rename it. Use the copytruncate directive in the configuration for that specific log.

1. Edit the config for the problematic service (e.g., /etc/logrotate.d/nginx).
2. For the block handling access.log and error.log, add copytruncate right after {:

   /var/log/nginx/*.log {
       copytruncate  # <-- Added
       daily
       missingok
       rotate 14
       compress
       delaycompress
       notifempty
       create 640 root adm
       sharedscripts
       postrotate
           [ ! -f /var/run/nginx.pid ] || kill -USR1 `cat /var/run/nginx.pid`
       endscript
   }
   

   copytruncate copies the current log to a new file and truncates the original, allowing the application to continue writing to the same descriptor. It's less atomic than the standard method (renaming) but solves locking issues.

Method 6: Force Run and Final Check

After making changes:

1. Force a rotation run (with the -f flag):

   sudo logrotate -f /etc/logrotate.conf
   

   If the command exits without errors — great.
2. Check that archives were created:

   ls -la /var/log/nginx/ | grep ".gz"
   

   Files like access.log.1.gz should appear.
3. Check that a new log file was created and is empty (or has size 0):

   sudo ls -la /var/log/nginx/access.log
   

4. Wait for the next scheduled run (or check in a day) and review system logs again for errors.

Prevention

1. Regular disk space monitoring. Add checks for /var to your monitoring systems (Zabbix, Prometheus, Nagios). A critical threshold is 80-90%.
2. Standardize permissions. Configure your applications (web servers, databases) to create logs with group write access that root can read. For example, for nginx: chown root:adm and chmod 640 for logs.
3. Annual audit of logrotate configurations. Check files in /etc/logrotate.d/ for obsolete paths or configs for uninstalled programs.
4. Use copytruncate deliberately. Apply this option only for applications that don't support log rotation signals (e.g., some Java apps). For nginx, Apache, haproxy, the standard method with postrotate/prerotate is better.
5. Test changes. Any change to logrotate configs or log permissions should be tested with sudo logrotate -d /etc/logrotate.conf before the system runs them automatically.

Method 7: Debugging with a Verbose Log (for Complex Cases)

If standard methods didn't help, enable maximum verbose logging for logrotate.

1. Create a file for the verbose log:

   sudo touch /var/log/logrotate-debug.log
   sudo chmod 644 /var/log/logrotate-debug.log
   

2. Run logrotate with all output (stdout and stderr) redirected to this file:

   sudo logrotate -d /etc/logrotate.conf 2>&1 | sudo tee /var/log/logrotate-debug.log
   

   Or for a real run (with -v for verbosity):

   sudo logrotate -vf /etc/logrotate.conf 2>&1 | sudo tee -a /var/log/logrotate-debug.log
   

3. Examine the resulting /var/log/logrotate-debug.log file. It will show the sequence of config reading, checking each file, and the exact point of failure. This is the most reliable diagnostic method.

Important: After diagnosis, remember to delete or clear the debug log so it doesn't itself cause disk space issues.