说到Linux定时任务的坑，那可真是让不少运维人员晚上睡不着觉的存在。就拿最基本的crontab来说，你以为设置几个数字就万事大吉了？天真！光是时区这个坑就能让你脚本集体罢工，更别说那些藏在角落里的奇葩问题了。记得有一次我们的日志轮转脚本在测试环境运行良好，一到线上就失灵了，排查了半天才发现是环境变量搞的鬼。
容易被忽略的PATH陷阱
crontab执行环境与普通shell环境有很大区别，特别是PATH环境变量。很多时候你在终端跑得好好的脚本，放到crontab里就报”command not found”。这是因为crontab默认只会使用极其有限的PATH设置，像/usr/bin、/bin这些基础路径，而那些你自己安装的工具可能都在/usr/local/bin下面。
修复方法很简单——要么在脚本里写全路径，要么在crontab开始处设置PATH：
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
邮件轰炸的烦恼
很多新手不知道，cron默认会把所有输出都通过邮件发送给用户。想想看，如果你有个每分钟运行一次的脚本，输出的日志又很多，很快你的邮箱就会被撑爆。更糟的是，有些服务器可能根本没配置邮件服务，结果是邮件队列持续堆积，直到把系统资源耗尽。
解决方法是在命令后添加重定向：
# 丢弃输出
* * * * * /path/to/script.sh >/dev/null 2>&1
# 或者写入日志文件
* * * * * /path/to/script.sh >>/var/log/script.log 2>&1
不过要提醒的是，这种做法虽然解决了邮件问题，但也可能掩盖真实错误。建议至少定期检查这些日志文件。
权限的微妙问题
你是否遇到过这种情况：手动运行脚本一切正常，通过cron执行就不行了？这可能是因为crontab在执行命令时会使用不同的用户权限和环境。比如以root用户设置的cron任务生成的日志文件，如果后面要用普通用户操作，就可能出现权限不足。
特别是在处理敏感文件（如/etc下的配置文件）时，这点尤为关键。我曾见过一个案例，备份脚本在测试时正常，实际运行却总失败，最后发现是因为cron运行时umask值不同，导致创建的文件权限与预期不符。
并发执行的潜在风险
假设你有个每分钟运行的脚本，有时候这个脚本可能会执行比较久。如果前一个实例还没结束，cron又会启动新的实例，这样就会导致脚本同时运行多个实例，可能引发资源竞争或数据损坏。
这时候就需要引入锁文件机制：
#!/bin/bash
LOCKFILE=/tmp/myscript.lock
if [ -e ${LOCKFILE} ] && kill -0 `cat ${LOCKFILE}`; then
exit
fi
trap "rm -f ${LOCKFILE}; exit" INT TERM EXIT
echo $$ > ${LOCKFILE}
# 实际业务逻辑...
rm -f ${LOCKFILE}
说到底，Linux定时任务看似简单，实则暗藏玄机。从环境变量到时区，从权限到并发控制，每个环节都可能让你栽跟头。最好的防御方式就是：保持警惕、日志记录、充分测试。你们在管理crontab时还遇到过哪些离奇的坑？欢迎分享你的血泪史。
评论