logrotate并非装上即用，需正确配置路径、触发条件及权限并验证执行：全局配置在/etc/logrotate.conf，服务级配置必须置于/etc/logrotate.d/；daily与size共存时满足任一即触发；postrotate需发信号重开日志；dateext须配dateformat避免跨年覆盖。
logrotate 不是“装上就能用”的工具，它默认只按周轮转、保留 4 份、不带日期后缀——这种配置对生产服务基本没用。真正起效的关键，在于**写对配置、选对触发条件、避开状态文件和权限陷阱**。
怎么判断 logrotate 是否真在跑你的配置？
很多人改完 /etc/logrotate.d/myapp 就等“自动生效”，结果磁盘还是爆了。根本原因是：logrotate 每天只读一次 /etc/logrotate.conf，而该文件末尾的 include /etc/logrotate.d/ 才会加载你写的配置。但加载≠执行——它仍要满足轮转条件（比如 daily 还没到时间、size 100M 还没达标）。
验证是否被识别的最直接方式是手动调试：
-
logrotate -d /etc/logrotate.d/myapp：只打印将做什么，不实际操作，看输出里有没有你的日志路径和“rotating log”字样 -
logrotate -v -f /etc/logrotate.d/myapp：强制立即执行，并显示详细过程（注意：-f 会真实切割） - 检查状态文件：
cat /var/lib/logrotate/logrotate.status | grep myapp，确认上次轮转时间是否更新
size 和 daily/weekly 冲突时谁说了算？
size 优先级高于时间类参数。也就是说，即使你写了 daily，只要日志还没涨到 size 50M，当天就不会轮转；反过来，哪怕才过 2 小时，只要日志突破 50M，logrotate 就会在下一次 cron 触发时（通常是次日凌晨）立刻处理。
常见误用：
- 写
daily+size 1G却期望“每天切一次”，结果日志常年不到 1G，永远不切 - 写
weekly+minsize 10M，但某次日志暴增到 500M，结果当周内就被切了两次（因为minsize是“至少达到才切”，不是“上限”） - 想实现“每 6 小时切一次”？
logrotate原生不支持，得自己改/etc/cron.hourly/脚本调用logrotate -f，并确保状态文件不冲突
为什么新日志文件一启动就空了？或程序继续往旧文件写？
这是最常被忽略的权限与信号问题。轮转后，logrotate 会创建新文件（靠 create），但应用进程仍持有旧文件描述符——它不知道文件已被重命名，还会继续往里面写。
Linux系统管理专家，覆盖12大模块：用户权限、SSH、存储、网络、systemd、防火墙、日志监控、备份恢复、TLS证书、Ansible、容器、IaC。提供配置、验证、加固、监控、备份、自动化、故障排查、回滚闭环。关键词：useradd、sudo、sshd_config、chmod、SEL...
解决必须靠 postrotate 发送信号让服务 reopen 日志：
- 对
rsyslog：postrotate /usr/bin/killall -USR1 rsyslogd endscript - 对
nginx：postrotate /usr/sbin/nginx -s reopen endscript - 对自研 Java 服务（用 logback）：需暴露 HTTP endpoint 或 JMX，
postrotate curl -X POST http://localhost:8080/log/reopen endscript - 如果服务不支持 reopen，只能用
copytruncate：先复制再清空原文件，但存在极小窗口丢失日志的风险（写入和 truncate 的间隙）
create 0644 root root 也容易出错：若应用以 www-data 身份运行，却试图往 root 创建的 0644 文件里写，会因权限拒绝而静默失败——此时应设为 create 0644 www-data www-data。
dateext 和 rotate 数字命名混用会怎样？
dateext 让归档文件带日期后缀（如 app.log-20260414），而默认数字后缀是 app.log.1、app.log.2……二者不能共存。一旦启用 dateext，rotate 30 就不再表示“保留最近 30 个文件”，而是“保留最近 30 天内生成的归档”——但前提是这些文件名真能被解析为有效日期。
坑点：
- 如果你用
dateext但没配dateformat %Y%m%d-%H，默认只认%Y%m%d，遇到app.log-20260414-12这种名字会被忽略，导致清理失效 -
rotate 7+dateext+daily看似合理，但如果某天没产生日志，那天的文件就不存在，实际可能只保留 5 个归档 - 不要手动删
.1类文件——logrotate的状态文件记录的是轮转序号，乱删会导致下次轮转错位（比如本该.1 → .2，结果发现没.1，直接覆盖原日志）
真正的难点从来不在语法，而在于理解它如何跟 cron、文件系统、进程生命周期咬合——少一个信号、错一个权限、漏一次调试，日志就可能悄无声息地失控。
