logrotate · Event logrotate exited abnormally
logrotate failed, and your disk is now filling up
Log rotation stopped working. Nothing breaks at the moment it fails — the consequence arrives weeks later when a partition fills and takes services down with it. That delay is why this quiet cron message is worth acting on the day it appears.
Also written as logrotate ALERT exited abnormallylogrotate failed cron
- How oftenUncommon
- Vendor calls itcron.err
- Logcron
What it means for you
For an analyst
logrotate stops at the first error in a configuration file rather than skipping past it, so one broken snippet in /etc/logrotate.d silently prevents everything after it from rotating. That is the failure mode that catches people — the message names one file and a dozen others are quietly not rotating too. Check the state file at /var/lib/logrotate/logrotate.status for the last successful rotation of each pattern; entries with old dates tell you the real scope, which the log message does not.
The fields that decide it
Everything else in the log line is context.
- The error text
- What actually went wrong. Each of the common ones has a distinct fix.
-
skipping because parent directory has insecure permissionsThe directory is group- or world-writable and logrotate refuses to act on it. A deliberate safety check, not a bug. -
error: error setting owner of ... : Operation not permittedThe configuration asks for an owner logrotate cannot set, common inside containers. -
error: stat of ... failed: No such file or directoryA configuration snippet for software that has been removed. -
ALERT exited abnormally with [1]The generic wrapper message from cron. The real error is on another line and is what you need. -
error: destination ... already exists, skipping rotationA previous run was interrupted, leaving a rotated file in the way. - The configuration file named
- Which snippet in /etc/logrotate.d failed. Everything processed after it in the same run may not have rotated either.
- Which logs stopped rotating
- Not in the message. Read /var/lib/logrotate/logrotate.status — the dates there show the true extent, which is usually wider than the error suggests.
- Free space on the affected partition
- The thing that actually matters. A rotation failure only becomes an incident when the disk fills.
Common questions
What does 'skipping because parent directory has insecure permissions' mean?
logrotate refuses to rotate logs in a directory that is writable by users other than its owner, because doing so could be used to trick it into writing somewhere it should not. The fix is to tighten the directory permissions — typically removing group and world write — rather than to override the check. The 'su' directive in the configuration is the supported way to handle directories owned by an application user.
Why did logrotate stop rotating logs it used to handle fine?
Most often because a new configuration snippet was added with an error in it. logrotate processes /etc/logrotate.d in order and stops at the first failure, so one broken file prevents everything after it from being handled. Run 'logrotate -d /etc/logrotate.conf' to walk the whole configuration in debug mode without changing anything — it names the failing snippet immediately.
How do I find out which logs are no longer being rotated?
Read /var/lib/logrotate/logrotate.status. It lists every pattern logrotate manages with the date it last rotated, so anything with an old date has been silently failing. This is more reliable than reading the error message, which names only the point where processing stopped rather than everything affected.
Can I just delete the large log file?
Deleting a file a process still has open frees no space at all — the space is only released when the process closes it, so the disk stays full and the file becomes invisible, which is worse. Truncate it instead with ': > /var/log/big.log', which frees the space while leaving the open file handle valid. Then fix the rotation.
Read next
- Usually comes before CRON CMD: a scheduled job ran The cron job that runs logrotate, and where the wrapper error text comes from.
- The equivalent of Failed to start: a systemd service did not come up On systems using the logrotate timer rather than cron, this is where the failure surfaces instead.
- Related Out of memory: the kernel killed a process to stay alive Another resource exhaustion event whose damage arrives long after the warning did.
- Read alongside SSH: connection closed before authentication finished High-volume auth logging, one of the most common reasons a log partition fills faster than expected.
Vendor documentation
Last reviewed 6 September 2026