logrotate后日志为空主因是服务未切换至新文件：旧inode仍被占用，postrotate发信号失败（pid路径错误/进程未收信号）、notifempty跳过轮转、create权限不匹配致服务无法写入。
logrotate 后日志文件为空，不是轮转失败，而是服务没切换到新文件——旧文件句柄还被进程占着，新文件没人写。
postrotate 里发信号没生效，Nginx/Apache/rsyslog 还在往旧 inode 写
最常见原因：postrotate 脚本里发的信号没送出去，或者目标进程根本没收到。
-
kill -USR1需要准确的 pid 文件路径，比如/run/nginx.pid或/var/run/nginx.pid，而不是硬写/usr/local/nginx/logs/nginx.pid（该路径下 pid 文件可能不存在） - 用
cat /proc/$(cat /run/nginx.pid)/fd/ | grep log看 Nginx 当前打开的是哪个日志文件的 inode；再对比ls -i /var/log/nginx/access.log，如果不一致，说明没切过去 - Apache 用
reload更稳妥：systemctl reload apache2；rsyslog 推荐kill -HUP $(pidof rsyslogd)，不是 USR1 - 脚本里别漏
if [ -f /run/nginx.pid ]; then ... fi，避免因 pid 文件缺失导致命令静默失败
配置里 missingok + notifempty 组合导致轮转被跳过
如果日志文件刚创建就为空，又开了 notifempty，logrotate 直接跳过整个轮转流程，不重命名、不创建新文件、也不触发 postrotate —— 表面看“轮转执行了”，其实什么都没干。
- 检查配置是否含
notifempty；若想确保每次轮转都强制创建新文件，改用ifempty（默认开启，不用显式写） - 用
logrotate -d /etc/logrotate.d/nginx调试，搜skipping或rotating pattern，确认目标文件是否真被纳入处理 - 临时去掉
notifempty测试，观察是否开始生成非空日志
create 权限或属主不匹配，新文件建出来了但服务无权写
logrotate 创建的新日志文件权限是 create 640 nginx nginx，但如果 Nginx worker 是以 www-data 用户跑的，就会写失败——文件存在，但 ls -l 看大小始终为 0。
- 查 Nginx 实际运行用户：
ps aux | grep nginx | grep -v master，看 worker 进程 UID - 查日志目录权限：
ls -ld /var/log/nginx，确保组可写且 GID 匹配（如nginx组需包含www-data用户） - 更稳妥的写法：
create 644 root root+su nginx nginx，让 logrotate 以目标用户身份创建文件
真正卡住的地方往往不在 logrotate 本身，而在它和具体服务之间那层“交接”——信号是否送达、pid 是否有效、用户权限是否对得上、inode 是否被释放。调试时盯住 lsof -p PID | grep log 和 stat 输出，比反复改配置更直接。
