日志中断主因是磁盘或inode耗尽而非进程崩溃。先用df -h和df -i快速判断空间与inode使用率，再通过lsof | grep deleted定位被删除但仍在写入的文件，结合journalctl和ls -lsh排查实际占用，最后验证权限与写入能力并采取清空句柄或重启服务等措施恢复。
日志中断往往不是进程挂了，而是写不进去——磁盘空间写满是最常见原因。排查要快、准、稳，重点不是“找大文件”，而是确认“为什么写不进”。
先看磁盘和 inode 是否真的满了
执行两条命令，5秒内判断基础状态：
- df -h：看根分区（/）或日志所在分区（如 /var/log）Use% 是否 ≥95%；
- df -i：看对应分区 IUse% 是否接近 100%，尤其在大量小日志文件场景下，inode 耗尽也会导致“No space left on device”，但 df -h 显示空间充足。
如果任一指标爆满，日志写入失败就是直接结果，无需再猜。
定位真实占用来源，避开 du 的“假象”
很多情况是：du 统计总和远小于 df 显示已用空间。这不是 du 错了，而是它看不见已被删除、但进程还在写的文件。
- 运行 lsof | grep deleted，重点检查输出中 size 列巨大的条目，常见于 nginx、java、rsyslog 进程持有的已删日志；
- 结合 journalctl --disk-usage 查 systemd 日志实际占用；
- 进入 /var/log 目录，用 ls -lSh | head -10 快速列出最大的几个日志文件，注意 .1、.2.gz 等轮转残留是否未清理。
验证日志服务是否仍在尝试写入
即使进程活着，也可能因句柄失效或权限丢失无法落盘：
- 查 main 实例当前打开的日志文件：lsof -p $(pgrep main) | grep log，确认路径是否存在、是否为 deleted 状态；
- 手动测试写入：echo "test" >> /var/log/main.log 2>&1，看是否报错；
- 检查日志目录权限：ls -ld /var/log 和 ls -l /var/log/main.log，确保服务用户有写权限。
临时恢复 + 长效预防
定位到问题后，动作要分两步走：
- 紧急释放：对 lsof 找出的 deleted 文件，可 kill 对应进程（如 kill -HUP $(pgrep nginx) 或重启服务），或用 truncate -s 0 /proc/PID/fd/FD_NUM 清空句柄内容（需 root）；
- 防复发：配置 logrotate（含 daily + rotate 7 + missingok + compress），禁用直接 rm 日志的操作；对高频小文件服务，设置 inode 预警阈值（如 IUse% >85% 告警）。
