别再 rm 日志了：Linux 下安全清空日志文件的正确姿势

日志文件越滚越大，磁盘告警一响，很多人的第一反应是 rm *.log 再 touch *.log。这个操作看起来干净利落，实际上埋着两个大坑。笔者在本文里把底层原因和两种安全做法讲清楚。

01 | 为什么 rm 加 touch 是危险操作

后台服务（比如 FastAPI、Nginx、MySQL）启动时就已经打开了日志文件，并在内存中持有该文件的 inode 和文件句柄（FD）。

执行 rm 只是删除了文件名与 inode 之间的映射链接。由于后台程序仍然持有这个 FD，操作系统不会真正释放磁盘空间，磁盘占用依旧居高不下。

紧接着执行 touch，会创建一个拥有全新 inode 的同名文件。但后台进程依然朝着旧的 FD 写入，新创建的 .log 文件永远收不到任何日志，直到服务重启为止。也就是说，磁盘没释放，日志还丢了。

02 | 单文件清空：true > 1.log

清空单个日志文件，最优雅的写法是：

bash 复制代码

true > 1.log

它由 Shell 直接调用底层的 open(..., O_TRUNC) 接口，在保持文件 inode、权限和文件句柄不变的前提下，瞬间把文件内容截断为 0 字节。

相比单纯的 > 1.log，加上 true 语义更明确，可避免某些交互式 shell 下对空重定向的歧义。需要注意：若开启了 noclobber，> 1.log 和 true > 1.log 都会因目标文件已存在而报错，此时应改用 >| 1.log 强制覆盖，或先关闭 noclobber；具体行为以所用 shell 版本和配置为准。

它的局限也很明显：重定向符号 > 属于 Shell 语法，无法配合通配符处理多个文件。

03 | 批量清空：truncate -s 0 *.log

需要一次清空多个日志时，首选：

bash 复制代码

truncate -s 0 *.log

-s 0（即 --size 0）指定把文件大小重置为 0 字节，效果同样是原地截断，具体底层实现以所用版本为准。truncate 原生支持文件名数组与 Shell 通配符展开，所以能直接对当前目录下所有匹配 .log 的文件一键截断。

在文件系统支持且进程按普通文件写入的前提下，它同样保留原文件的 inode、权限和所有者，后台写入进程通常无需重启，磁盘空间随之释放。执行前请先确认通配符匹配到的文件确实是日志文件，并确保有相应写权限。

04 | 三种方式对比

操作方式	适用场景	批量支持	安全性 / 进程影响
`rm .log` + `touch .log`	严禁使用	-	高危：磁盘空间锁死、新日志无法写入
`true > 1.log`	清空单个日志文件	否	安全：瞬间清空，不卡顿，不影响进程
`truncate -s 0 *.log`	批量清空日志文件	是	最推荐：语义清晰，原生支持多文件

三种方式在"是否保留 inode"这一维度上的差异，直接决定了进程能否继续正常写日志：
flowchart TD START $"需要清空日志"$ --> Q1{"文件数量?"} Q1 -->|单个文件| A $"true \> 1.log\保留 inode，安全"$ Q1 -->|多个文件| B $"truncate -s 0 \*.log\保留 inode，安全"$ Q1 -->|误用| C $"rm \*.log + touch \*.log\inode 变更，高危"$ A --> OK $"进程无感知，空间释放"$ B --> OK C --> BAD $"空间不释放 + 新日志丢失"$

记住一句话：清空日志要截断内容，而不是删除文件。单文件用 true > 1.log，批量用 truncate -s 0 *.log。在生产环境执行前，建议先确认目标文件、必要时备份或转存历史日志，并优先在测试环境验证。

By the way, 操作之前一定要确认你要操作的log真的是可以删除的无用日志，如果不确认就找负责的人确认清楚，可不要单纯认为所有的.log都可以删除，举个例子，最典型的，比如Oracle数据库的redo.log就绝对不能删除！！因为这种误操作的案例实际是太多了，值得强调提醒下...

关注我，和AI一起成长~