安全清空日志文件应使用 truncate -s 0 或 > file，不删除文件、保留 inode 和权限、不中断服务；避免 echo "" > file 等误操作；清空后建议触发服务 reopen 释放空间。

安全清空正在写入的日志文件，核心原则是：不删除文件、不改变 inode 和权限、不中断服务进程的文件句柄。只要日志文件仍被服务打开（比如 nginx、tomcat、docker 容器），就绝不能用 rm，而应选择“逻辑清空”方式。

优先用 truncate -s 0

这是最稳妥的选择，尤其适合大文件（几 GB 以上）或对一致性要求高的场景：

• 直接修改文件系统中的大小字段，毫秒级完成，完全不触发磁盘 I/O 写入
• 保留所有元数据：权限、属主、SELinux 上下文、ACL、硬链接、inode 号都不变
• 即使文件正被 tail -f 或服务持续追加写入，也能立即生效——内核会重置该文件描述符的写入偏移，后续日志从头开始写
• 命令示例：sudo truncate -s 0 /var/log/nginx/access.log

常用且轻量的 > file

Shell 内置重定向，速度快、语义清晰，适合中小日志（几百 MB 级别）：

Zynq Linux Hardware Debug

Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。

下载

• 本质是把文件长度设为 0，不调用外部程序，开销极小
• 同样保留 inode、权限、时间戳（mtime 更新，atime 不一定变）
• 注意：sudo > file 无效——> 是 shell 操作，需用 sudo sh -c '> file' 或切换 root 执行
• 命令示例：sudo sh -c '> /var/log/syslog'

避免踩坑的几个关键点

有些看似相似的操作，实际存在隐患：

• echo "" > file 会写入一个换行符，文件大小变成 1 字节，可能被 logrotate 或 Java FileAppender 误判，引发轮转异常或日志错位
• rm file && touch file 会丢失权限、SELinux 上下文、硬链接，新文件 inode 号变更，inotify/rsync 可能出问题
• cat /dev/null > file 效果等同于 > file，但多一次 fork 开销，脚本中可读性略好，非必须
• 对只读文件（如部分 journal 日志）、/proc 或 /sys 下的伪文件、mmap 映射的文件，truncate 和 > 都会失败，需先确认文件类型和属性

清空后要不要通知服务？

多数现代服务（如 nginx、rsyslog）支持日志 reopen，清空后建议主动触发，让服务重新打开文件，确保磁盘空间真正释放：

• nginx：sudo nginx -s reopen
• systemd-journald：sudo systemctl kill --signal=SIGUSR1 systemd-journald
• 自定义服务：查文档看是否支持 USR1 或 HUP 信号
• 不确定时，可用 lsof +D /var/log 2>/dev/null | grep your-log 确认 fd 是否还指向旧文件