根分区被/var/log/messages撑爆本质是logrotate轮转失效，需排查配置缺失、定时任务未执行、权限错误及syslog服务未重载四大原因，否则清空后问题重现。
根分区被 /var/log/messages 类日志撑爆，本质是日志轮转机制失效或配置不当，导致单个日志文件持续追加、体积失控。排查需聚焦“为什么没轮转”，而非仅清空文件——否则问题很快重现。
确认 messages 文件是否真的异常膨胀
先验证问题现象是否属实：
- 运行
ls -lh /var/log/messages，若大小超过 1GB（尤其达数 GB 或几十 GB），基本可判定为未轮转主因 - 对比同目录下轮转后的归档文件，如
/var/log/messages.1、/var/log/messages.2.gz是否存在且有合理时间戳；若完全缺失或只有极老的备份，说明轮转长期未执行 - 检查文件修改时间：
stat /var/log/messages中Modify时间若远晚于Change时间，可能被 truncate 过但未触发轮转
检查 logrotate 配置是否覆盖 messages
logrotate 不会自动管理所有日志，必须有明确配置项。重点查三处：
- 主配置：
cat /etc/logrotate.conf，确认是否包含/var/log/messages或通配规则（如/var/log/*.log） - 服务专属配置：
ls /etc/logrotate.d/ | grep -E "(rsyslog|syslog|journal)"，常见路径如/etc/logrotate.d/rsyslog或/etc/logrotate.d/syslog-ng，打开后确认其中是否有/var/log/messages块 - 配置内容是否有效：例如是否误写成
/var/log/message（少 s），或路径被注释掉，或使用了错误的用户权限（如要求create 0644 root root但实际目录属主是syslog）
验证 logrotate 是否真正执行过
配置存在 ≠ 按时运行。常见失效点：
- 定时任务未启用：
systemctl list-timers | grep logrotate查看 cron 是否注册了 logrotate 定时器；或检查/etc/cron.daily/logrotate是否存在且可执行 - 手动测试轮转：
sudo logrotate -d /etc/logrotate.conf（调试模式），观察输出中是否出现rotating pattern和renaming /var/log/messages等关键行；若提示skipping "/var/log/messages" because parent directory has wrong owner or permissions，说明权限不匹配 - 检查最近执行记录：
grep "logrotate" /var/log/syslog或journalctl --since "2 days ago" | grep logrotate，确认近期是否有成功执行日志
排查 syslog 服务与轮转的协同问题
即使 logrotate 配置正确，若日志服务未配合重载，旧文件句柄仍被占用，轮转后空间无法释放：
- 查看 rsyslog 或 syslog-ng 是否在运行：
systemctl status rsyslog或systemctl status syslog-ng - 确认其配置中是否启用了
copytruncate（安全但非默认），或依赖postrotate脚本 reload：cat /etc/logrotate.d/rsyslog | grep -A5 postrotate，应含类似invoke-rc.d rsyslog rotate >/dev/null或systemctl kill --signal=SIGHUP rsyslog.service - 若无 reload 逻辑，轮转后 rsyslog 仍在往已重命名的旧文件写入（因文件描述符未关闭），导致磁盘空间不释放——此时需手动
kill -HUP $(pidof rsyslogd)或重启服务
