logrotate没生效主因是未被cron触发；missingok与create共用易致日志丢失；size与daily为或关系，需minage折中；/etc/logrotate.d/文件按字典序加载，调试用-d查看实际配置。
logrotate 没生效？先确认它是否真在运行
很多配置写完没效果，不是语法错，而是 logrotate 根本没被触发。它默认不常驻，靠 cron 定时调用，常见路径是 /etc/cron.daily/logrotate。如果系统没启用 daily cron（比如某些容器或精简版系统），配置再对也白搭。
实操建议：
- 手动执行一次验证：
sudo logrotate -d /etc/logrotate.conf（-d是 debug 模式，不实际轮转，只打印行为） - 检查 cron 是否启用：
systemctl list-timers | grep logrotate或看/var/log/syslog里有没有 cron 执行记录 - 容器环境常需额外加 crond 启动，或改用
logrotate -f主动触发
rotate 之后日志丢了？注意 missingok 和 create 权限冲突
missingok 看似安全，但和 create 一起用容易出问题：如果旧日志被误删、路径不存在，logrotate 会跳过创建新文件（因为 missingok 让它“假装没看见”），导致后续程序写日志失败，看似静默，实则断流。
实操建议：
- 生产环境慎用
missingok；更稳妥的是用notifempty配合create -
create的权限参数要匹配应用用户，比如 Nginx 日志常用：create 0644 www-data www-data，而不是 root - 若日志路径是软链，
logrotate默认操作目标文件而非链接本身，需加copy或copytruncate明确行为
按大小 + 时间双条件轮转？logrotate 本身不支持 AND 逻辑
logrotate 的 size 和 daily/weekly 是 OR 关系：满足任一即触发。想实现“每 100MB 且至少一天才轮转”，它做不到原生支持。
实操建议：
- 折中方案：用
size主控，配合minage 1（单位天），确保即使写得快，也不会在同一天内多次轮转 - 极端场景需精确控制，得外挂脚本：先用
stat -c %y /path/to/log判断修改时间，再决定是否调用logrotate -f -
maxage和rotate要配对用，否则老日志删不干净；maxage按最后修改时间算，不是轮转时间
多个配置文件加载顺序混乱？/etc/logrotate.d/ 下的优先级不等于文件名顺序
logrotate 读取 /etc/logrotate.d/ 下所有文件，但顺序由 glob 展开决定（通常是字典序），不是按修改时间或配置先后。一个服务的日志规则若被另一个文件覆盖（比如都匹配 /var/log/*.log），结果不可控。
实操建议：
- 每个服务单独配独立文件，文件名用前缀避免冲突，如
nginx、myapp，别叫01-nginx或z-myapp - 用
include显式引入公共片段（如统一压缩命令），避免重复写compresscmd - 调试时加
-d会打印实际加载的配置块，重点关注 “reading config file” 行，确认哪段生效了
真正麻烦的是嵌套 include 和通配路径重叠——这种时候，logrotate -d 输出里的 “considering log file” 和 “does not need rotating” 就是唯一可信线索。
