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

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

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

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

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

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

下面这张图展示了 rm + touch 之后，进程、旧 inode 与新文件之间的错位关系：

flowchart LR P["后台进程<br/>持有旧 FD"] -->|持续写入| OLD["旧 inode<br/>磁盘空间未释放"] RM["rm *.log"] -.->|删除文件名映射| OLD TOUCH["touch *.log"] -->|创建| NEW["新 inode<br/>同名 .log 文件"] P -.->|不再指向| NEW NEW -->|永远收不到日志| EMPTY["空文件"]

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

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

true > 1.log

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

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

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

截断操作的关键在于“原地清空”，进程与 inode 的绑定关系保持不变：

flowchart LR P["后台进程<br/>持有 FD"] -->|持续写入| INODE["原 inode<br/>inode / 权限 / FD 不变"] TRUNC["true > 1.log<br/>open O_TRUNC"] -->|截断为 0 字节| INODE INODE -->|磁盘空间立即释放| FREE["空间回收"]

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

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

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<br/>保留 inode，安全"] Q1 -->|多个文件| B["truncate -s 0 *.log<br/>保留 inode，安全"] Q1 -->|误用| C["rm *.log + touch *.log<br/>inode 变更，高危"] A --> OK["进程无感知，空间释放"] B --> OK C --> BAD["空间不释放 + 新日志丢失"]

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

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

关注我，和AI一起成长~