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