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 执行边界——配错一行，可能三周后才在磁盘告警里暴露。
