sharedscripts 仅在同一配置块内防止重复执行 postrotate/prerotate，跨文件或跨块互不影响；不控制日志轮转本身，仅限制脚本执行频次。
sharedscripts 不是用来“优化性能”的，而是防止重复执行 reload 类操作——用错地方反而会引发服务中断或日志丢失。
sharedscripts 只对同一配置块内的路径生效
logrotate 判断是否“共享脚本”的依据是：所有日志路径是否写在同一个 {} 块里。跨文件、跨配置块的 sharedscripts 互不影响。
- ✅ 正确：把
/var/log/nginx/*.log和/var/log/nginx/error.log写在同一段中，加sharedscripts，哪怕匹配出 10 个文件，postrotate也只跑一次 - ❌ 错误：在
/etc/logrotate.d/nginx和/etc/logrotate.d/app里各自写一个sharedscripts块，它们完全独立，各自触发自己的systemctl reload nginx - ⚠️ 注意：
sharedscripts不影响轮转本身（切割、压缩、删除），只控制postrotate/prerotate的执行频次
不加 sharedscripts 时 reload 会被反复触发
假设你配置了 /var/log/myapp/*.log { ... postrotate systemctl reload myapp.service endscript }，且该目录下有 access.log、error.log、audit.log 三个文件：
- logrotate 会为每个匹配到的文件单独执行一遍
postrotate - 结果就是连续三次
systemctl reload myapp.service，可能造成服务抖动、连接中断 - 尤其当应用对
SIGHUP敏感（如旧版 Nginx）或 reload 本身耗时较长时，问题更明显 -
sharedscripts就是为解决这个而设：只要本轮有任一文件被轮转，postrotate就只执行一次
copytruncate + sharedscripts 组合要格外小心
copytruncate 是先拷贝再清空原文件，适合正在被进程持续写入的日志；但它和 sharedscripts 搭配时容易埋雷：
- 如果多个日志路径共用一个
postrotate，但其中某些路径实际没被轮转（比如大小未达标），copytruncate仍会对所有匹配路径执行——包括那些没变的文件 - 更危险的是：
copytruncate清空的是原始文件，若postrotate里有kill -USR1或systemctl reload，而应用还没来得及 reopen 日志文件，新日志可能直接写进空文件，导致内容错乱 - 建议：对使用
copytruncate的场景，优先确保所有路径确实需要统一 reload；否则宁可拆成独立块，避免误清空
验证 sharedscripts 是否真生效的最快方法
别靠猜，用 -d（debug）模式看 logrotate 实际行为：
logrotate -d /etc/logrotate.d/myapp
重点关注输出里是否出现类似：
rotating pattern: /var/log/myapp/*.log after 1 days (7 rotations)considering log /var/log/myapp/access.logconsidering log /var/log/myapp/error.log-
running postrotate script← 只出现一次，说明sharedscripts生效 - 如果看到多次
running postrotate script，说明配置没落在同一块里，或者被其他配置覆盖了
真正容易被忽略的点是：logrotate 加载顺序和覆盖逻辑——/etc/logrotate.conf 里的全局设置会被 /etc/logrotate.d/ 下同名参数覆盖，但 sharedscripts 这种开关类指令不会“继承”，必须显式写出。
