Logs that never rotate: two usual causes

/var/log/app.log reached tens of gigabytes despite a rule in logrotate.d. Run it by hand first:

logrotate -d /etc/logrotate.d/app

The dry run prints which configs it read and why it skipped them. Two common outcomes.

The file lives in a subdirectory that /etc/logrotate.conf never includes, so the rule is invisible.

Or rotation happens and the process keeps writing to the old inode, because it opened the file once and still holds the descriptor:

postrotate
    systemctl reload app >/dev/null 2>&1 || true
endscript

copytruncate works too, but loses whatever is written between copy and truncate. Not a good trade for busy services.