logrotate 全局配置放 /etc/logrotate.conf，服务级配置必须置于 /etc/logrotate.d/ 目录；daily 与 size 共存时满足任一即触发轮转；postrotate 脚本需校验 pid 文件路径、加 || true 防中断；dateext 务必配
dateformat -%Y%m%d避免跨年覆盖。
logrotate 配置文件该放哪儿？别乱放
全局策略写在 /etc/logrotate.conf，服务级配置必须丢进 /etc/logrotate.d/ 目录下——这是硬性约定，不是建议。系统 cron（通常是 /etc/cron.daily/logrotate）只扫描这个目录里的文件，放错位置（比如直接改 /etc/logrotate.conf 里 include 行却没配对路径）会导致配置完全不生效。
常见错误：把 nginx 日志配置写成 /etc/logrotate.conf 里的一个 block，结果每次更新主配置都要手动 diff，还容易被包管理器覆盖。正确做法是单独建 /etc/logrotate.d/nginx，权限保持 644，属主 root。
daily / size / rotate 这三个参数怎么配才不翻车
daily 和 size 100M 可以共存，但 logrotate 是「满足任一条件即触发」，不是「同时满足」。比如你设了 daily + size 10M，而某天日志只写了 2MB，它仍会在次日凌晨轮转；反之若日志 3 小时就冲到 10MB，它会立刻轮转——这可能打乱你的归档节奏。
- 高频小日志（如调试日志）：优先用
size，避免空转 - 低频稳定日志（如 audit.log）：用
daily或weekly更可控 -
rotate 14指保留 14 个归档文件，但注意：如果启用了compress，实际磁盘占用远小于 14×原始日志大小；若禁用压缩，14 天 × 每天 500MB = 7GB，得提前算账
postrotate 脚本为什么总失效？关键在信号和权限
Nginx、rsyslog 等服务需要收到 USR1 信号才能重新打开日志文件，但脚本执行时很可能没权限读 pid 文件或发信号。典型失败现象：轮转后新日志一直为空，旧日志还在被追加。
正确写法必须带防御逻辑：
postrotate if [ -f /var/run/nginx.pid ]; then kill -USR1 $(cat /var/run/nginx.pid) 2>/dev/null || true fi endscript- 绝对路径检查 pid 文件，不能依赖
$PATH - 用
|| true防止脚本非零退出导致整个轮转中断 - 如果服务跑在非 root 用户下（如 systemd –user），
su nginx nginx得加在配置块开头，否则kill会被拒绝
dateext 和 compress delaycompress 的组合陷阱
dateext 会让归档文件名带上日期（如 access.log-20260129），看着清爽，但它和 compress 一起用时有个坑：delaycompress 会跳过最新一轮归档的压缩，但如果你又开了 dateext，那「最新一轮」指的是带日期的文件，而非 .1 后缀的文件——这可能导致你误以为压缩没生效。
更麻烦的是：dateext 默认不带年份，2026 年 1 月 1 日轮转的文件叫 access.log-0101，2027 年同一天又会出现同名文件，直接覆盖。务必加上：
dateformat -%Y%m%d否则跨年归档会乱套。另外，delaycompress 和 rotate 数值要匹配好——比如 rotate 7 却没开 delaycompress，第 8 天轮转时会立刻删掉最老的压缩包；开了则第 7 天的包等到第 8 天轮转时才压，第 9 天才删。
真正难搞的从来不是语法，而是时间、权限、信号、路径这四样东西在不同服务间微妙的错位。配完别光看 cron 是否运行，一定要手动跑一次 logrotate -f -v /etc/logrotate.d/yourconf，盯着输出里有没有 Error 或 skipping —— 那些才是真问题。