logrotate配置文件必须放在/etc/logrotate.d/目录下（如/etc/logrotate.d/nginx），系统每日通过/etc/cron.daily/logrotate扫描该目录自动加载执行；放错路径（如/root/）将不被读取，且需确保日志路径与nginx实际配置一致。
logrotate 配置文件放哪？必须是 /etc/logrotate.d/nginx
不是 /etc/logrotate.conf，也不是随便建个路径。系统每天通过 /etc/cron.daily/logrotate 扫描 /etc/logrotate.d/ 目录下的所有文件，自动加载执行。把配置放错位置（比如放在 /root/ 或 /tmp/），logrotate 根本不会读它。
确认 nginx 日志路径是否匹配：默认是 /var/log/nginx/*.log，但如果你改过 access_log 指令（比如写成 /opt/logs/nginx/access.log），配置里必须严格对应，否则轮转不生效。
- 用
grep access_log /etc/nginx/nginx.conf确认实际路径 - 如果用了多个
server块且日志路径不同，要么统一路径，要么在配置中用通配符覆盖（如/opt/logs/nginx/**/*.log，需 logrotate ≥ 3.18 且启用 glob） - 配置文件名不一定要叫
nginx，但建议保持一致，避免和其他服务冲突
postrotate 里 reload 还是 kill -USR1？选对信号才生效
Nginx 不支持 systemctl reload 在所有环境都可靠——比如容器里没 systemd，或者用 nginx -c 启动时未注册为 service。直接发信号更通用：
- 推荐写成：
kill -USR1 `cat /var/run/nginx.pid 2>/dev/null` || true -
USR1是 Nginx 的“重新打开日志文件”信号，比 reload 更轻量、更确定 - 确保
pid文件路径和 nginx 启动参数一致（默认/var/run/nginx.pid，若改过pid指令就得同步改这里） - 不要用
nginx -s reload：它依赖 PATH 和 nginx 二进制位置，容易因环境变量缺失失败
为什么日志没按天切？检查 cron 和 daily 的真实含义
daily 不代表“一到 00:00 就切”，而是“每天 cron 运行 logrotate 时判断：如果距上次轮转已满 24 小时，就触发”。所以首次配置后，可能要等最多 24 小时才看到效果。
- 手动测试：运行
sudo logrotate -vf /etc/logrotate.d/nginx，加-v看详细过程，-f强制执行 - 确认 cron 是否真在跑：
ls -l /etc/cron.daily/logrotate，再查grep logrotate /var/log/syslog或journalctl -u cron | grep logrotate - 别混淆
weekly：它固定在周日执行（不是“每七天”），且依赖系统时区设置；monthly固定每月 1 号，同样受时区影响
copytruncate 和 create 到底该用哪个？看 nginx 进程权限
两者本质冲突，不能同时用。选错会导致新日志写不进、权限错误或轮转后空白：
- 用
create 0644 www-data www-data：要求 nginx 主进程以www-data身份运行，且有权限在/var/log/nginx/下创建文件 —— 这是最常见、最推荐的方式 - 用
copytruncate：先拷贝日志再清空原文件，适合 nginx 无法重启、也不能改属主的场景（如某些嵌入式部署），但存在极小概率丢失最后一段写入（毫秒级） - 如果 nginx 是 root 启动但 worker 进程降权为
www-data，create仍有效；但copytruncate后原文件属主不变，可能造成后续写入权限拒绝
postrotate 发信号会失败，但轮转本身仍完成——结果就是旧日志被重命名，新日志却没人写，看起来“日志消失了”。上线前务必用 sudo systemctl status nginx 确保服务稳定。
