SECURITY WARNING: Never run commands you don't understand. Always review code before execution. Use at your own risk.
Logging New Added 12 September 2026

logrotate: skipping because parent directory has insecure permissions

logrotate refuses to rotate a file in a directory that is group or world writable, because doing that work as root would be an escalation path. Nothing else breaks, so rotation just stops and the disk fills a few weeks later, long after the message scrolled past in the timer output.

Quick fix

Read the commands before running them. Anything that restarts a service, deletes data or changes permissions should be tried on a non-production system first.

Quick fix
# See exactly which file it is skipping, without rotating anything
sudo logrotate -d /etc/logrotate.conf 2>&1 | grep -B2 insecure

# Check the directory, not the file
ls -ld /var/log/app

# Either tighten the directory
sudo chmod g-w,o-w /var/log/app

# Or tell logrotate which user to rotate as, which is the right answer when
# the application genuinely needs to write there
# /etc/logrotate.d/app
/var/log/app/*.log {
    su appuser appgroup
    daily
    rotate 14
    compress
    missingok
}

How to diagnose Logging errors

Logging failures are dangerous because they are silent: the application keeps running while its telemetry disappears. The recurring causes are buffer overflow under backpressure (the destination cannot keep up), permissions on log files or directories, and ingestion rate limits at the cloud provider. Monitoring the logging pipeline itself is the only reliable way to notice.

If the quick fix above does not resolve it, work through these steps. They apply to this whole class of error, not just to this one message, which is usually what saves the time.

  1. Check the collector's own logs first: Fluentd, Logstash and the CloudWatch agent all log their own failures, usually to a separate destination.
  2. Look for backpressure metrics: buffer queue length, retry counts, and dropped-record counters. A full buffer means the destination, not the collector, is the bottleneck.
  3. Verify write permissions and disk space on the buffer path. A full disk silently stops most collectors.
  4. For cloud ingestion, check the API rate limit for the log group or stream and batch more aggressively rather than retrying harder.
  5. Add a heartbeat log line and alert on its absence. This is the only way to detect a pipeline that has stopped without erroring.

Tools worth reaching for

  • collector self-logs
  • buffer/queue metrics
  • df -h
  • aws logs describe-log-streams
  • logger / fluent-cat for test events

Authoritative references

Primary documentation for this error, worth reading before applying any fix in production.

github.com

Related Logging errors

See all 9 Logging errors →

Browse other categories

Something missing or wrong?

This entry is maintained by hand. If the fix is out of date, incomplete, or you have a better one, email a correction and it will be reviewed.