Why logrotate silently does nothing and how to actually debug it

Logrotate misconfigurations often go unnoticed, silently failing rather than failing loudly. A common issue arises with the copytruncate directive, which copies a log file and truncates it in place. On a busy server, this can lead to dropped log entries. The solution is to use the postrotate approach, which reloads the process cleanly without race conditions or dropped lines.

However, logrotate returning a 0 exit code doesn't necessarily mean the rotation was successful. It could be due to various reasons such as missing files, wrong paths, permission issues, or config directives that don't apply. To verify the actual state, run logrotate with the -d flag in debug mode, which prints what it would do without executing it. This is crucial before applying any config changes.

When debugging, focus on key areas: renaming logs, empty log warnings (indicating missing or zero-size source files), and error strings (pointing to permission or path issues). If you see "log needs rotating" without "renaming," it indicates the maxsize or rotations-per-day limit has been reached, and the file was skipped intentionally.

The most common cause of disk fill-ups isn't malicious activity but rather a logrotate config that lacked compress on a high-volume file, going unnoticed for months due to a lack of disk alerts. The second most common issue is a process holding onto a file descriptor after logrotate has moved the file, causing the rotated file to remain on disk until the process restarts.

Using the command "lsof +L1" can quickly identify this problem. In summary, verify postrotate hooks, test logrotate with -d before deploying configs, and include "lsof +L1" in your disk-full checklist.