脚本手动跑正常 cron 里就不执行:一次 Linux 定时任务排查复盘

2024 年,我写了一个数据备份脚本,逻辑很简单:打包目录、上传到对象存储、删掉三天前的旧包。我在命令行里手动跑了好几遍,每次都干净利落地成功。于是我把它丢进 crontab,设成每天凌晨两点执行,心满意足地下班了。第二天我去看备份,没有。第三天,还是没有。我第一反应是 cron 没在跑,可 systemctl status crond 一看,服务好好的;我又翻 crontab -l,那一行配置清清楚楚就在那。我把脚本路径复制出来,在命令行里再跑一遍——成功,毫无问题。这下我彻底糊涂了:同一个脚本,我手动跑能成,cron 跑就是不成,而 cron 服务本身明明活得好好的。我盯着这个矛盾想了很久,最后才意识到:我犯了一个想当然的错误——我以为 cron 执行我的脚本,和我自己在终端里执行它,是"同一回事"。可它们根本不是。cron 把脚本跑起来时,那个脚本所处的"环境",和我登录终端后所处的"环境",是两个截然不同的世界。这件事逼着我把 Linux 的 cron 执行机制、环境变量、PATH、shell 登录差异这一整套彻底理清了。本文复盘这次实战。

问题背景

环境:CentOS 7,一个备份脚本 /opt/scripts/backup.sh
事故现象:
- 脚本在命令行手动跑,每次都成功
- ★ 放进 crontab 设凌晨 2 点执行,连续几天都没产出
- crond 服务正常、crontab -l 配置也在

现场排查:
# 1. cron 服务是好的
$ systemctl status crond
   Active: active (running)              # ★ 服务正常

# 2. crontab 配置也在
$ crontab -l
0 2 * * * /opt/scripts/backup.sh         # ★ 配置没问题

# 3. ★ 看 cron 到底有没有"试着跑"
$ grep CRON /var/log/cron | tail
... CROND[12450]: (root) CMD (/opt/scripts/backup.sh)
# ★ 日志说明:cron【确实在 2 点执行了】这个命令

# 4. ★ cron 跑了,却没产出 —— 那就是脚本"跑挂了"
#    给 crontab 那行加上重定向,把输出抓下来:
$ crontab -e
0 2 * * * /opt/scripts/backup.sh > /tmp/backup.log 2>&1
# 第二天看 /tmp/backup.log:
$ cat /tmp/backup.log
/opt/scripts/backup.sh: line 8: aws: command not found  # ★ 找不到 aws
/opt/scripts/backup.sh: line 3: BACKUP_DIR: unbound variable # ★ 变量没了

根因(后来想清楚的):
1. ★ cron 执行脚本时,给的【环境】和我登录终端时
   的环境,完全是两回事。我手动跑能成,是因为我
   终端里的环境"恰好"齐全 —— 但那不是脚本自带的。
2. ★ PATH 不一样。cron 跑任务时,PATH 极其精简
   (常常只有 /usr/bin:/bin)。我装在
   /usr/local/bin 里的 aws 命令,cron 找不到。
3. ★ 我登录时由 ~/.bashrc / ~/.bash_profile 设的
   环境变量(比如 BACKUP_DIR),cron 【根本不加载
   这些文件】—— 所以那个变量在 cron 里是空的。
4. 脚本里用了相对路径 / 依赖"当前目录",而 cron
   执行时的工作目录和我手动跑时也不一样。
5. ★ 一句话:脚本能在我的终端里跑通,靠的是我
   终端环境的"施舍";它自己【并不是自给自足的】。
   一旦换到 cron 那个干净环境,它立刻就散架了。
"手动能跑,cron 不能跑" = 脚本依赖了终端环境里它没自带的东西。

修复 1:第一步永远是——确认 cron 到底跑没跑

# === ★ 别瞎猜:先把"cron 有没有执行"这件事坐实 ===

# === 看 cron 自己的日志 ===
# cron 每执行一条任务,都会在系统日志里留一行记录:
$ grep CRON /var/log/cron | tail -20
# CentOS:/var/log/cron
# Ubuntu/Debian:/var/log/syslog,grep CRON
$ journalctl -u crond --since today        # systemd 系统也可这样看

# === ★ 根据日志,分成两种完全不同的情况 ===
# 情况 A:日志里【没有】你那条任务的 CMD 记录
#   -> cron 压根没去执行它。问题在【任务没被触发】:
#      时间写错了 / crontab 没生效 / 服务没起。
#      (见修复 2)
# 情况 B:★ 日志里【有】CMD 记录,任务却没效果
#   -> cron 执行了,是【脚本自己跑挂了】。
#      问题在脚本的运行环境。(见修复 3、4)

# === ★ 一条日志看出是 A 还是 B ===
$ grep CRON /var/log/cron | grep backup.sh
Apr 10 02:00:01 CROND[12450]: (root) CMD (/opt/scripts/backup.sh)
# ★ 有这行 = 情况 B(cron 跑了,脚本挂了)—— 我这次。
# ★ 没这行 = 情况 A(cron 根本没触发)。

# === ★ 情况 B 的关键:把脚本的输出抓出来 ===
# cron 执行脚本,脚本的 stdout/stderr【默认会被丢弃】
#   (准确说,是被当成邮件发给用户,而服务器多半
#    没配邮件 -> 等于丢了)。所以你看不到任何报错。
# ★ 解法:在 crontab 里【强制把输出重定向到文件】:
$ crontab -e
0 2 * * * /opt/scripts/backup.sh > /tmp/backup.log 2>&1
#                                 ^^^^^^^^^^^^^^^^^^^^^
#   > 文件   把标准输出写进文件
#   2>&1     把标准错误也【并到】标准输出里一起写
# ★ 加上这个,下次 cron 一跑,所有报错就都躺在
#   /tmp/backup.log 里了 —— 排查 cron 问题第一件事。

# === 认知 ===
# ★ cron 问题排查,第一步永远是分清:是【没跑】,
#   还是【跑了但挂了】。看 /var/log/cron + 抓输出。
#   跳过这步瞎猜,十有八九查错方向。

修复 2:情况 A——cron 根本没触发的几个坑

# === ★ 如果日志里压根没有你的任务:它没被触发 ===

# === 坑 1:时间字段写错了 ===
$ crontab -l
0 2 * * * /opt/scripts/backup.sh
# cron 的五个时间字段:分 时 日 月 周
#  - 0 2 * * *   -> 每天 02:00
#  - ★ 常见错:把"每 5 分钟"写成 5 * * * *
#    (这其实是"每小时的第 5 分钟"执行一次)
#    每 5 分钟应该是  */5 * * * *
#  - ★ 日 和 周 同时指定,是【或】的关系,容易反直觉

# === ★ 坑 2:crontab 最后一行没有换行 ===
# 一个非常隐蔽的坑:crontab 文件的【最后一行】如果
#   没有以换行符结尾,这一行任务可能【不会被执行】。
# ★ crontab -e 编辑完,确保最后敲一个回车留个空行。

# === 坑 3:编辑了 /etc/crontab 或 cron.d,少写了用户名 ===
# 两类 crontab,格式【不一样】:
#  - crontab -e(用户级):分 时 日 月 周 + 命令
#  - ★ /etc/crontab 和 /etc/cron.d/*(系统级):
#    分 时 日 月 周 + 【用户名】 + 命令
$ cat /etc/cron.d/mytask
0 2 * * * root /opt/scripts/backup.sh
#               ^^^^ ★ 系统级 cron 多这一列用户名,漏了就不执行

# === 坑 4:改的是别的用户的 crontab ===
# crontab 是【按用户分开】的。
$ crontab -l            # 看的是【当前用户】的
$ sudo crontab -l -u root   # 看 root 的
# ★ 你用普通用户 crontab -e 编辑,任务就以普通用户身份
#   跑;别指望它有 root 权限。要 root 跑就 -u root。

# === 坑 5:crond 服务没起 / 没开机自启 ===
$ systemctl status crond
$ systemctl enable --now crond     # 确保运行 + 开机自启

# === ★ 坑 6:任务被 cron.deny 挡了 ===
$ cat /etc/cron.deny     # 在这里面的用户,不允许用 cron
# ★ 如果你的用户在 cron.deny 里,crontab 直接不让用。

# === 验证:临时设成"下一分钟"试跑 ===
# 别等凌晨 2 点。先设成下一分钟,确认能触发:
$ crontab -e
* * * * * /opt/scripts/backup.sh > /tmp/t.log 2>&1
# ★ 等一分钟,看 /var/log/cron 有没有 CMD 记录、
#   /tmp/t.log 有没有内容 —— 验证完再改回正式时间。

修复 3:情况 B 的真凶——cron 的环境是"干净"的

# === ★ cron 跑了脚本却挂了:几乎都是"环境"问题 ===

# === ★ 我手动跑能成,凭的是什么 ===
# 我登录 SSH,系统给我开一个【登录 shell】。这个过程
#   会自动加载一连串文件:/etc/profile、~/.bash_profile、
#   ~/.bashrc …… 它们给我的 shell 灌满了环境变量:
#   一个很长的 PATH、各种自定义变量、别名……
# ★ 我手动跑脚本时,脚本继承了这一整套"丰盛"的环境。
#   脚本里那些没定义的变量、没写全路径的命令,
#   都靠我这个环境【替它兜着】。

# === ★ cron 给的是什么环境 ===
# cron 执行任务时,【不是】一个登录 shell。它【不会】
#   加载 /etc/profile、不会加载 ~/.bashrc。
# 它只给极少几个环境变量,最关键的:
#  - PATH:★ 通常极短,常常就是 /usr/bin:/bin
#  - SHELL:/bin/sh
#  - HOME、LOGNAME
# ★ 没有了。你 ~/.bashrc 里设的一切,cron 全不知道。

# === ★ 亲眼看看 cron 的环境有多"穷" ===
# 在 crontab 里临时加一行,把 cron 的环境打出来:
$ crontab -e
* * * * * env > /tmp/cron_env.txt
# 等一分钟,然后:
$ cat /tmp/cron_env.txt
HOME=/root
LOGNAME=root
PATH=/usr/bin:/bin             # ★ 看!PATH 就这么短
SHELL=/bin/sh
# ★ 把它和你终端里 echo $PATH 一比,差距一目了然。
#   你终端 PATH 里的 /usr/local/bin 等等,cron 里没有。

# === 我那两个报错,根因对上了 ===
# - "aws: command not found"
#   ★ aws 装在 /usr/local/bin/,不在 cron 的 PATH 里。
# - "BACKUP_DIR: unbound variable"
#   ★ BACKUP_DIR 是我在 ~/.bashrc 里 export 的,
#     cron 不读 ~/.bashrc,这个变量自然是空的。

# === ★ 一句话 ===
# cron 不是"环境坏了",是它【本来就给一个最小环境】。
#   脚本在终端能跑,是终端环境惯着它;到了 cron,
#   惯着它的人没了,它自己的"先天不足"就全暴露了。

修复 4:让脚本"自给自足"——不依赖外部环境

# === ★ 根治思路:脚本要能在"最干净的环境"里独立跑 ===

# === 办法 1:命令一律用绝对路径 ===
# 不要写  aws s3 cp ...
# ★ 要写完整路径:
$ which aws
/usr/local/bin/aws
# 脚本里就写:
/usr/local/bin/aws s3 cp ...
# ★ tar、gzip、find 这些也一样 —— 不确定路径就 which
#   一下。绝对路径 = 不依赖 PATH,放哪都能找到。

# === ★ 办法 2:在脚本开头自己把 PATH 设全 ===
# 比逐个写绝对路径更省事:脚本第一行就把 PATH 补齐。
#!/bin/bash
export PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
# ★ 这样脚本里再写 aws、tar 就都找得到了。

# === ★ 办法 3:脚本需要的环境变量,自己定义 ===
# 别指望 ~/.bashrc 帮你 export。脚本要用什么变量,
#   就在脚本里【自己写死或自己读配置】:
#!/bin/bash
BACKUP_DIR=/data/backup            # ★ 脚本里自己定义
S3_BUCKET=my-backup-bucket
# 或者集中放一个配置文件,脚本开头 source 它:
source /opt/scripts/backup.conf    # ★ 用绝对路径 source

# === 办法 4:不要依赖"当前工作目录" ===
# cron 执行时,工作目录通常是用户的 HOME,不是你
#   想的那个目录。脚本里别用相对路径。
#!/bin/bash
cd /opt/scripts || exit 1          # ★ 要用某目录,自己 cd 进去
# 或者用脚本自身所在目录:
SCRIPT_DIR=$(cd "$(dirname "$0")" && pwd)

# === ★ 办法 5:在 crontab 顶部统一设环境 ===
# crontab 文件里,任务行之前可以直接写环境变量:
$ crontab -e
PATH=/usr/local/bin:/usr/bin:/bin      # ★ 对下面所有任务生效
BACKUP_DIR=/data/backup
0 2 * * * /opt/scripts/backup.sh > /tmp/backup.log 2>&1
# ★ 但更推荐把环境收进脚本自己 —— 脚本走到哪都自洽。

# === ★ 办法 6:终极验证 —— 模拟 cron 的干净环境跑一遍 ===
# 用 env -i 清空所有环境变量,模拟 cron 那种"裸奔":
$ env -i /bin/bash --noprofile --norc -c '/opt/scripts/backup.sh'
# ★ 如果脚本在这种"什么都没有"的环境里也能跑通,
#   那它放进 cron 就一定能跑通。这是最硬的验证。

修复 5:正确解法——写一个"经得起 cron 考验"的脚本

# === ★ 把一个能在 cron 里稳定跑的脚本,整个写出来 ===

# === 一个健壮脚本的标准开头 ===
#!/bin/bash
# --- 1. 严格模式:出错立刻暴露,别让脚本"带病前进" ---
set -euo pipefail
#  -e :任何命令失败,脚本立即退出
#  -u :★ 用了未定义的变量,立即报错(而不是当空值)
#  -o pipefail :管道里任一环节失败,整条管道算失败

# --- 2. ★ 自己把 PATH 设全,不靠 cron ---
export PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

# --- 3. ★ 脚本自己接管日志,不依赖 cron 的重定向 ---
LOG=/var/log/backup.log
exec >> "$LOG" 2>&1                # 之后所有输出都进日志
echo "===== $(date '+%F %T') backup start ====="

# --- 4. 需要的变量,自己定义或读配置 ---
BACKUP_DIR=/data/backup
S3_BUCKET=my-backup-bucket

# --- 5. ★ 切到确定的工作目录,不靠 cron 给的 ---
cd "$BACKUP_DIR" || { echo "cd 失败"; exit 1; }

# === ★ 关键操作都用绝对路径 ===
/usr/bin/tar czf backup.tar.gz ./data
/usr/local/bin/aws s3 cp backup.tar.gz "s3://$S3_BUCKET/"
/usr/bin/find . -name 'backup-*.gz' -mtime +3 -delete

echo "===== $(date '+%F %T') backup done ====="

# === ★ crontab 那一行,也要稳 ===
$ crontab -e
# 即使脚本自己写了日志,这里也再兜一层,接住脚本启动
#   前就崩掉的极端情况(比如脚本文件本身没执行权限):
0 2 * * * /opt/scripts/backup.sh >> /var/log/backup_cron.log 2>&1

# === ★ 上线前的检查清单 ===
# 1. 脚本有执行权限:  chmod +x /opt/scripts/backup.sh
# 2. 第一行 shebang 对:#!/bin/bash(不是 #!/bin/sh 又用了
#    bash 特性)
# 3. ★ 用 env -i 干净环境跑通:见修复 4 办法 6
# 4. crontab 时间字段核对:用在线 cron 解析器验证一下
# 5. ★ 先设"下一分钟"试跑一次,确认产出和日志都对
# 6. 再改回正式时间(0 2 * * *)

# === 验证它真的在 cron 里跑成了 ===
$ grep CRON /var/log/cron | grep backup        # cron 触发了
$ tail /var/log/backup.log                     # 脚本日志有 done
$ ls -lh /data/backup                          # 产物真的生成了
# ★ 三个都对上,才算这个 cron 任务真正可靠了。

修复 6:cron 排查纪律

# === 这次事故暴露的认知盲区,定几条纪律 ===

# === 1. ★ cron 排查第一步:分清"没跑"还是"跑了挂了" ===
$ grep CRON /var/log/cron | grep 你的脚本
# 有 CMD 记录 = 跑了挂了;没有 = 根本没触发。

# === 2. ★ cron 任务必须重定向输出,否则报错全丢 ===
$ ... >> /tmp/x.log 2>&1     # 不加这个,你永远看不到错

# === 3. ★ cron 不是登录 shell,不读 ~/.bashrc /etc/profile ===
# 你登录环境里的 PATH、变量,cron 一概没有。

# === 4. cron 的 PATH 极短,命令要用绝对路径或脚本里设 PATH ===

# === 5. ★ 脚本要"自给自足":变量自己定义,目录自己 cd ===

# === 6. ★ 上线前用 env -i 模拟干净环境跑通 ===
$ env -i /bin/bash --noprofile --norc -c '/path/script.sh'

# === 7. 别等正式时间,先设"下一分钟"验证能触发、有产出 ===

# === 8. 排查"cron 不执行"的步骤链 ===
$ systemctl status crond              # ① 服务活着吗
$ grep CRON /var/log/cron             # ② 触发了没
$ 给任务加 >>log 2>&1                 # ③ 跑了就抓输出看报错
$ env -i 模拟环境跑脚本               # ④ 复现环境问题
$ 命令绝对路径 + 脚本内设 PATH/变量   # ⑤ 让脚本自洽
# 按这个顺序,cron 不执行基本能定位、能根治。

命令速查

需求                        命令
=============================================================
看 cron 服务状态            systemctl status crond
看 cron 执行日志            grep CRON /var/log/cron
看当前用户的 crontab        crontab -l
编辑当前用户的 crontab      crontab -e
看指定用户的 crontab        crontab -l -u 用户名
给任务抓输出                任务后加  >> /tmp/x.log 2>&1
打印 cron 的环境            crontab 加一行  * * * * * env > /tmp/e.txt
模拟 cron 的干净环境跑脚本  env -i /bin/bash --noprofile --norc -c '脚本'
查命令的绝对路径            which 命令名
看 systemd 定时器(替代)   systemctl list-timers

口诀:cron 排查先分清没跑还是跑了挂了,任务必须重定向输出否则报错全丢
      cron 不读 ~/.bashrc PATH 极短,命令用绝对路径,脚本要自给自足

避坑清单

1. cron 排查第一步是看 /var/log/cron 分清任务是根本没触发还是触发了但脚本跑挂了
2. cron 执行脚本的 stdout 和 stderr 默认会被丢弃,任务必须加重定向否则永远看不到报错
3. cron 执行任务不是登录 shell,不加载 /etc/profile 和 ~/.bashrc,登录环境的变量它都没有
4. cron 的 PATH 极短常常只有 /usr/bin:/bin,装在 /usr/local/bin 的命令会 command not found
5. 脚本能手动跑通靠的是终端环境的施舍,脚本本身要自给自足才经得起 cron 的干净环境
6. 命令一律用绝对路径,或在脚本开头自己 export PATH 把路径补全
7. 脚本需要的环境变量要自己定义或 source 配置文件,别指望 cron 帮你加载
8. cron 执行时工作目录通常是用户 HOME,脚本里别用相对路径,要用就自己 cd 进去
9. 上线前用 env -i 清空环境模拟 cron 跑一遍,能跑通才说明脚本不依赖外部环境
10. 系统级 /etc/crontab 和 cron.d 的格式比用户 crontab 多一列用户名,漏写整行不执行

总结

这次"脚本手动跑能成、放进 cron 就死活不成"的事故,纠正了我一个关于"执行"的、藏得很深的误解。在我的脑子里,"执行一个脚本"这件事,长久以来是一个没有上下文的、纯粹的动作:我把脚本写好,它就是一段确定的逻辑,无论谁来按下那个"运行"的按钮,无论在什么时候按,结果都该是一样的——脚本里写了什么,它就做什么。我手动在终端里敲下脚本路径,和 cron 在凌晨两点替我敲下同样的路径,在我看来,是同一件事的两个无关紧要的版本。正因为我心里有这个"执行与环境无关"的假设,所以"手动能跑、cron 不能跑"这个现象,对我来说是彻底无法理解的:同样的脚本、同样的机器、同样的命令,凭什么换了个发起者,结果就天差地别?我反复地手动跑、反复地确认 cron 服务还活着,我就是不肯接受"脚本本身没问题、是环境的问题"——因为在我的认知里,"脚本"和"环境"压根就不是两样东西,脚本就是全部。复盘到根上,我才明白,一个脚本从来都不是孤立运行的。它每一次执行,都被包裹在一个"环境"里——一组环境变量、一个 PATH、一个工作目录、一套被加载过的配置文件。这个环境,就像空气一样,平时你感觉不到它的存在,可脚本里的每一行,其实都在呼吸着它:你写 aws 这个命令,是 PATH 这个环境变量在背后帮你把它翻译成磁盘上某个具体的可执行文件;你用一个变量 BACKUP_DIR,是某个被加载过的配置文件在背后早早地把它定义好了。我手动跑脚本的时候,我登录 SSH 这个动作,已经在我毫不知情的情况下,替我把这个环境布置得无比丰盛——系统加载了 /etc/profile、加载了我的 ~/.bashrc,给我一个长长的 PATH、一屋子现成的变量。我的脚本在这个被精心布置过的房间里跑,当然一切顺利。可它顺利,不是因为它自己有多完备,而是因为这个房间替它兜住了所有的"想当然"。而 cron,它给脚本的是另一个房间——一个几乎空无一物的、干净到近乎简陋的房间。cron 执行任务时根本不是一次"登录",它不会去加载 /etc/profile,不会碰我的 ~/.bashrc,它只给一个短得可怜的 PATH 和寥寥几个变量。我的脚本被扔进这个空房间,那些它一直以来"想当然"地依赖着、却从来不曾自己声明过的东西——那个命令的路径、那个变量的值——一瞬间全都不在了,它当场就散了架。这次最大的收获,是我意识到,我一直以来都高估了我写的代码的"独立性"。我以为我交付的是一段"自给自足"的逻辑,可实际上,我交付的是一段"依赖大量隐含前提"的逻辑——而那些前提,我自己甚至都没意识到它们的存在,因为在我习惯的那个环境里,它们总是默默地、稳定地、被满足着。我从来没有声明过"我需要 PATH 里有 /usr/local/bin",因为我的终端里它一直都在;我从来没有声明过"我需要 BACKUP_DIR 这个变量",因为我的 ~/.bashrc 一直替我准备着。这些没有被声明出来的依赖,就是一颗颗定时炸弹,平时被环境的惯性压着,一旦换了个环境,就集中引爆。所以下一次,当我写一个要交给"别人"去执行的东西——交给 cron、交给另一台机器、交给一个容器、交给一个 CI 流水线——我会强迫自己做一件事:我会假设它将在一个"什么都没有"的、最贫瘠的环境里运行,然后逐行去审视,问我自己,这一行用到的每一个命令、每一个变量、每一个路径,究竟是这个脚本【自己带来的】,还是它【指望环境施舍的】?凡是指望施舍的,我都要把它显式地、亲手地写进脚本里。一个真正可靠的脚本,不应该是一个在舒适房间里被惯坏的孩子,它应该是一个能在任何空房间里都活得下去的、自给自足的成年人。

—— 别看了 · 2026