如何截断修改时间超14天的日志文件？所用命令失效求助

你所用的命令语法没有本质错误，失效基本都是以下几个常见原因导致：

• 查找路径错误：命令中.代表执行命令时的当前工作目录，如果你执行命令时不在日志存放的目录下，自然找不到目标.log文件，操作系统日志、应用日志时建议直接写绝对路径，比如/var/log、/data/app/logs这类。
• 时间匹配偏差：-mtime +14的判定规则是文件最后修改时间距当前时间大于14个完整24小时（即336小时），不是自然日计算的14天，如果需要精确匹配14天的分钟级时间差，替换为-mmin +20160（14天合计20160分钟）即可。
• 权限不足：系统日志、服务运行日志通常归属root或对应服务账户，普通用户没有写入权限，truncate操作会静默失败，操作这类文件需要在命令前加sudo提权。
• 命令兼容问题：部分精简容器、定制化发行版默认没有带truncate（属于coreutils组件），会直接报命令不存在的错误。
• 活跃日志的句柄问题：如果目标日志正被运行中的服务打开写入，直接truncate清空后，部分服务不会重置文件写入指针，会导致文件生成空洞——前半部分全是空字节，磁盘空间不会实际释放，后续日志从原偏移位置开始写入，看起来就像截断没生效。

可用命令 #

通用兼容写法（不依赖truncate命令，所有POSIX兼容shell都能跑）：

# 将/path/to/your/logs替换为实际日志存放的根路径，需要提权就在前面加sudo
find /path/to/your/logs -name '*.log' -type f -mtime +14 -exec sh -c '> "$1"' _ {} \;

如果确认环境有truncate，也可以用更直接的写法：

sudo find /var/log -name '*.log' -type f -mmin +20160 -exec truncate -s 0 {} \;

注意 #

生产环境的服务活跃日志不建议手动直接截断，优先用logrotate配置日志轮转，工具会自动在截断后给服务发送重新打开日志的信号，避免出现文件空洞、日志丢失、磁盘空间不释放的问题。如果手动截断后出现空间未释放、日志不再写入的情况，需要重启对应服务，或者给服务发送指定信号重开日志句柄（比如Nginx用kill -USR1 <nginx主进程PID>）。

内容的提问来源于stack exchange，提问作者Praveen