早上收到监控告警，根分区使用率 96%。登上去一看，/var/log/nginx 下三个文件各占几个 G，日志从半年前就没切过。logrotate 的配置在，定时任务也在，就是一直没生效。
主配置只管默认值
/etc/logrotate.conf 里通常只放全局默认，加一行 include /etc/logrotate.d，真正的轮转规则写在那个目录下的各个文件里。主文件的 daily、rotate、compress 是默认值，单个文件可以覆盖。改完不用重启服务，下一次触发就会读新配置。
一个能用的段落长什么样
路径写在最前面，后面跟大括号。里面依次是 daily 表示按天切，rotate 14 表示留十四份，compress 打开压缩，delaycompress 让最新那份先不压，missingok 表示文件不存在也不报错，notifempty 表示空文件跳过，create 0640 指定新文件的权限和属主。nginx 还需要在 postrotate 里给主进程发 USR1 信号，让它重新打开日志文件。
为什么没生效
先跑 logrotate -d /etc/logrotate.conf，调试模式只打印不执行，能看到它读了哪些文件、判定切不切。常见原因有几个：配置文件是全局可写，logrotate 出于安全直接跳过；状态文件 /var/lib/logrotate.status 记着上次轮转时间，没到周期不动；路径写错或者通配符没匹配上。
触发方式也容易忽略。老一点的发行版走 /etc/cron.daily/logrotate，新版用 systemd 的 logrotate.timer。cron 服务没开、timer 被禁用，配置写得再对也不会执行。看一眼 timer 的状态就知道。
几个参数的实际影响
copytruncate 适合不支持重新打开日志的程序，先复制再清空，代价是复制那几秒写入的内容可能丢。create 后面的权限和属主必须和程序运行身份一致，写错会导致重启后写不进日志。想立刻验证，用 -f 强制跑一次，看目录里有没有带日期后缀的新文件。别在业务高峰做，几个 G 的文件压缩会吃满一个核。
判断标准：日志能删就删，要留就按天切、留两周、压缩存。