Linux 定时删除日志的命令哪里容易写错，怎么排查？

问题

服务器上应用日志越堆越多，照网上抄了一条定时删除的命令放进 crontab，结果要么到了点根本没删，要么删出来吓一身冷汗。到底哪个地方容易写错？怎么排查才稳妥？

原因

自写"定时删日志"脚本是误删事故的高发区，常见毛病有这几个：

1. crontab 里的百分号要转义。% 在 crontab 中是特殊字符（表示换行），命令里出现 date +%Y%m%d 这类写法必须把 % 转义，否则整条命令在那里被截断。
2. 环境变量不一样。定时任务执行时的 PATH 和你终端里不同，命令最好写绝对路径，比如 /usr/bin/find，不然就出现"手动能跑、定时不行"。
3. -mtime 理解偏差。-mtime +7 是"7 天以前"，-mtime 7 是"恰好第 7 天"，差一个号含义完全不同。
4. 删了正在写入的日志，空间不释放。文件还被应用进程持有时，删除后空间并不还给磁盘，一看容量没变，很容易误判成"没删干净"而继续加大力度，越搞越乱。

稳妥的排查与做法

第一步，只打印、不删除，先验证名单。把删除动作换成打印，手动跑一遍： find /var/log/你的应用目录 -name "*.log" -mtime +7 -print 看输出里是不是全都是确实该删的旧日志。这一步是纯只读操作，绝对安全。

第二步，确认定时任务到底执行没有。看 cron 的执行日志（tail /var/log/cron，或 systemd 系统用 journalctl -u crond --since today），执行记录和报错八成在这里现形。

第三步，优先用系统自带的日志轮转，而不是自己写删除。主流发行版都带 logrotate：按天数或大小自动"轮转—压缩—到期删除"，配置里写清保留份数即可；系统日志（journald）本身也能设容量上限，超了自动清理。用系统机制，比任何自写删除脚本都稳。

第四步，如果一定要自写脚本，先立三条规矩：① 命令必须同时带 -name 和 -mtime 限定，只指向应用日志目录，永远不指向系统目录；② 先用"只打印"模式在定时任务里跑一周，确认输出无误再切换成删除动作；③ 正在写入的日志要先让应用重新打开日志文件（或计划内重启应用），否则删了空间也不释放。

警示

rm 加上 -f 之后没有任何"回收站"可谈，网上"删库跑路"的真实案例大都是这类脚本路径写错造成的。改任何删除逻辑前，先问自己一句：如果这条命令的目录变量是空的，它会删掉什么？

预防

• 日志目录独立分区或配容量监控，别等到盘满才动手。
• 所有清理脚本进版本管理，改动留记录，出问题能回溯。

日志治理、磁盘水位这类运维细活，贵州诚鑫致达科技可以按"数据管家"的方式托管，让服务器别再靠删日志续命。

来源：https://ask.csdn.net/questions/333196