如何在Linux中配置定时垃圾清理任务

千万别在 crontab 里直接硬编码 rm 命令，这背后藏着不少坑。普通用户往往没权限动系统目录，cron 默认的 PATH 又窄得可怜，经常导致命令找不到；再加上错误输出没重定向，任务就静默失败了，甚至因为缺乏锁机制引发并发误删。至于靠文件名或日期来判断删除对象，更是不可靠。正确的做法是：用 root 权限封装脚本，显式声明解释器和绝对路径，配合 -daystart 与 -mtime 精准定位，务必加上锁机制、日志记录，并用 -print 先做测试，这样才够安全。

直接用 crontab 写 rm 命令清理垃圾，90% 的情况会静默失败或误删——权限、路径、环境、时间判断全都不对。必须封装脚本，用 root 权限调度，加锁+日志+绝对路径+-mtime 判断。

为什么不能在 crontab 里直接写 rm 命令

常见错误是往普通用户的 crontab -e 里加一行：0 2 * * * rm -rf /tmp/*。它看似每天跑，实则几乎从不生效：

• 普通用户没权限删 /tmp 下其他用户创建的文件（Permission denied 被 cron 丢弃，你根本看不到）
• rm 在 cron 环境下找不到，因为默认 $PATH 只有 /usr/bin:/bin，而有些系统把 rm 放在 /bin/rm
• 没重定向输出，错误全消失，你以为任务成功了
• 没加锁，如果前一次清理卡住，下次又触发，可能并发删一半正在写的缓存

必须用 sudo crontab -e 编辑 root 任务

清理 /tmp、/var/log、/var/cache 这类目录，脚本必须以 root 身份运行。编辑方式只有一种正确写法：

• 执行 sudo crontab -e，不是 crontab -e
• 不要在 crontab 行里写 sudo rm：cron 下 sudo 不会弹密码框，直接卡死或退出码 1
• 系统级任务别塞进用户 crontab；也不要用 /etc/crontab 手动改（易被包管理器覆盖），统一走 sudo crontab -e

脚本里必须显式声明解释器和绝对路径

哪怕你本地 bash 能直接跑，cron 默认用 /bin/sh 执行，且不加载 profile。脚本开头必须写：

#!/bin/bash

然后 crontab 中调用时也得显式指定解释器：

• 写成 0 2 * * * /bin/bash /usr/local/bin/clean-junk.sh >> /var/log/clean.log 2>&1
• 所有命令用绝对路径：/usr/bin/find、/bin/rm、/usr/bin/date，别信 which find 的结果
• 测试前先模拟 cron 环境：env -i /bin/bash --noprofile --norc /usr/local/bin/clean-junk.sh，能立刻暴露路径/变量问题

用 -mtime +N 判断，别解析文件名日期

靠 backup_20240501.tar.gz 这种名字判断过期，极不可靠：

• 文件被 touch 修改过时间戳，-mtime 就失效了
• 命名不规范（比如多一个下划线、少一位数），正则就漏掉
• 时区错位导致“明明该删却没删”或“刚写完就被删”

正确做法是基于最后修改时间（即实际写入完成时间）：

• /usr/bin/find /backup -type f -name "*.tar.gz" -daystart -mtime +7 -print：先 -print 确认列表，没问题再换 -delete
• -daystart 让计算从当日 00:00 开始，避免因任务执行时间浮动（比如凌晨 2:03 跑）导致延迟一天
• 加 -maxdepth 1 防止递归进子目录误删；加 -type f 明确只处理文件

最容易被忽略的是锁文件和日志重定向——没锁，两个清理任务撞上可能删掉正在生成的备份；没重定向，find: cannot open ... Permission denied 这类关键错误你永远看不到。