不能用 rm -f /var/log/messages，因为 rsyslogd 等服务已打开该文件并持有 inode，rm 仅删除目录项，进程仍向原 inode 写入导致磁盘空间不释放且可能引发异常；应使用 truncate -s 0 保留 inode 安全清空。
直接清空 /var/log/messages 是安全的，但必须避免 rm 删除文件本身——否则正在写入日志的 rsyslogd 或 syslog-ng 进程会持续向已删除文件的 inode 写入，磁盘空间不释放，且可能引发服务异常。
为什么不能用 rm -f /var/log/messages
系统日志服务（如 rsyslogd）在启动时打开 /var/log/messages 并保持文件句柄。一旦你 rm 掉它，文件虽从目录中消失，但进程仍在往原 inode 写数据，df 显示磁盘未释放，lsof | grep deleted 会看到类似 rsyslogd ... /var/log/messages (deleted) 的条目。这不是“清空”，是制造隐患。
truncate -s 0 /var/log/messages 是最推荐的做法
该命令将文件逻辑大小设为 0 字节，保留 inode、权限、属主、时间戳，且对正在写入的进程完全透明——rsyslogd 不会感知任何变化，继续追加新日志。
- 执行前确认服务状态：
systemctl is-active rsyslog（或syslog-ng） - 单次清空：
sudo truncate -s 0 /var/log/messages - 想同时清空关联日志（如
secure、maillog）：sudo truncate -s 0 /var/log/{messages,secure,maillog} - 验证是否生效：
stat /var/log/messages查看Size:是否为0，且Modify:时间已更新
其他可用方法及关键区别
> /var/log/messages 和 cat /dev/null > /var/log/messages 效果类似，也保留 inode，但有细微差异：
-
> /var/log/messages：shell 内置重定向，最快，无额外进程开销；但若文件权限为只读（如某些加固环境），会报Permission denied -
cat /dev/null > /var/log/messages：依赖cat命令和 shell 重定向，兼容性略广；但多一次进程 fork，且若/dev/null不可读（极罕见）会失败 -
echo -n "" > /var/log/messages：等效于第一种，但-n避免写入换行符；不推荐用于日志清空，因为echo在某些精简 shell（如dash）里行为不一致 -
sed -i 'd' /var/log/messages：会重建文件（inode 变更），导致rsyslogd实际停止写入旧文件——除非你手动kill -HUP重载，否则新日志会丢失
清空前务必检查的三件事
真正出问题的往往不是清空动作本身，而是上下文没理清：
- 确认日志服务是否启用：
systemctl list-unit-files | grep -E "(rsyslog|syslog-ng)"，禁用状态下清空无意义，启用状态下才需保 inode - 检查磁盘是否真被日志占满：
du -sh /var/log/* | sort -hr | head -5，别只盯着messages，journal或nginx日志可能才是元凶 - 确认是否需要保留最近内容：如果只是腾空间，
truncate最安全；如果要归档分析，先cp /var/log/messages /backup/messages.$(date +%F)再清空
真正容易被忽略的是：很多运维脚本用 echo > file 清空，却没加 sudo，结果静默失败；或者批量操作时通配符匹配到非日志文件（比如 /var/log/installer 目录），truncate 会报错退出——加 -f 参数（truncate -sf 0 ...）可跳过不可写文件，但得确保你真想忽略它们。
