安全清空日志文件应使用 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 是否还指向旧文件
