Linux 日志轮转 logrotate 配置方法

logrotate 配置文件默认为 /etc/logrotate.conf，并通过 include /etc/logrotate.d/ 加载该目录下所有文件；新配置应放 /etc/logrotate.d/myapp，需 root 所有、权限 644，由 cron 每日触发执行，无需重启服务。

logrotate 配置文件写在哪？权限和加载时机怎么确认

logrotate 不是靠“启动服务”生效的，它依赖 cron 每天调用 /usr/sbin/logrotate 执行一次。配置文件默认读取 /etc/logrotate.conf，再通过 include /etc/logrotate.d/ 加载目录下所有文件。你加的新配置，放 /etc/logrotate.d/myapp 最稳妥。

• 文件必须由 root 所有，权限建议设为 644（chmod 644 /etc/logrotate.d/myapp），否则 logrotate 会静默跳过
• 修改后不用重启任何服务，但要等 cron 下次执行（通常是每天凌晨）；调试时可手动运行 logrotate -d /etc/logrotate.conf 查看模拟过程（-d 是 debug 模式，不真删日志）
• 如果你的应用日志路径含变量或软链接，logrotate 默认不跟踪重命名后的目标——得加 copytruncate 或配 create，否则可能丢日志

rotate 5 和 maxage 30 同时存在时，哪个先起作用

两者逻辑不同，不是互斥关系：rotate 控制本地保留几份归档（比如 app.log.1 到 app.log.5），maxage 是按最后修改时间删掉超过 N 天的归档（哪怕还没轮满 5 次）。

• 实际保留数量 = min(当前归档数, rotate 值)，但每份归档还会被 maxage 单独检查：如果某份 app.log.3 修改时间距今 31 天，即使 rotate 5 还没满，它也会被删
• 注意 maxage 只对已归档文件（即带数字后缀的）生效，不影响当前正在写的 app.log
• 时间判断基于文件 mtime，不是日志内容里的业务时间；如果你用 copytruncate，归档文件的 mtime 就是截断时刻，相对可靠

nginx 日志被切了但 access.log 还在增长，新日志没写进去

这是最常踩的坑：logrotate 重命名了 access.log，但 nginx 进程仍持有原文件描述符，继续往旧 inode 写。现象是磁盘空间没释放，access.log 看似空了但 du 显示仍占空间。

• 必须让 nginx 重新打开日志文件，标准做法是在 logrotate 配置里加 postrotate 段：

  postrotate   if [ -f /var/run/nginx.pid ]; then       kill -USR1 `cat /var/run/nginx.pid`   fi endscript

• kill -USR1 是 nginx 的“重新打开日志”信号，不是重启；用 systemctl reload nginx 也行，但更重，且可能触发配置校验失败
• 不要用 create 替代：它会新建空文件，但 nginx 不会自动切过去，除非配合 USR1 或 reload
• 其他服务类似：rsyslog 用 kill -HUP，redis 用 redis-cli bgrewriteaof（不适用日志轮转）或直接 reload，关键看服务是否支持平滑 reopen

gzip 压缩后日志打不开，或者解压报 “unknown method”

logrotate 调用 gzip 时默认用 --best（即 -9），但某些老旧系统或嵌入式环境里的 gzip 版本不支持高阶压缩参数，导致生成的 .gz 文件无法被标准工具识别。

• 最稳写法是显式指定 compresscmd /bin/gzip 和 compressext .gz，并加 compressoptions -6（中等压缩比，兼容性好）
• 如果用 delaycompress，注意它只延迟上一轮压缩，不是跳过压缩；配合 missingok 可避免因日志文件临时消失导致轮转中断
• 验证压缩结果：手动跑一遍 gzip -t /var/log/nginx/access.log.1.gz，报错就说明压缩命令有问题；别等半夜报警才发现日志全压坏了

logrotate 看似简单，但每个开关背后都连着文件系统行为、进程 I/O 模型和 cron 执行边界——配错一行，可能三周后才在磁盘告警里暴露。