crontab到点不执行，PATH、绝对路径、权限和cron日志四步该怎么按顺序排查？

目录

一、导语：一个被低估的“环境契约”问题

几乎每个维护过 Linux 服务器的人都遇到过这样的场景：在终端里手动执行 /opt/app/bin/backup.sh 一切正常，写进 crontab 之后到了预定时间却毫无动静，/var/log/cron 里甚至看不到任何执行记录。于是排查往往从“cron 服务是不是没启动”开始，绕一大圈之后才发现，问题出在脚本里一行 python3 上——cron 的 PATH 里根本没有 /usr/local/bin。

这类故障之所以反复出现，是因为它挑战了一个根深蒂固的直觉：“我手动能跑，说明配置没问题。”但 cron 并不是在“你的终端”里执行任务，而是在一个由守护进程构造的、经过刻意裁剪的最小环境中执行任务。两者之间的差异不是偶然的 bug，而是设计使然。本文把这种差异称为执行环境契约断裂（execution environment contract breakage）：任务编写者默认了一套环境假设，cron 实际提供的却是另一套，二者没有显式对齐，故障便以“不执行”的形式暴露出来。

笔者认为，把 crontab 故障理解为“环境契约问题”而非“语法问题”，是排查效率的分水岭。语法错误通常在 crontab -e 保存时就会被提示；而环境契约断裂是静默的——任务可能根本没被调度，可能被调度了但命令找不到，可能命令找到了但权限不足，也可能一切正常只是输出被丢弃。四步排查法的价值，就在于用固定顺序把这种静默差异逐层显性化。

二、背景与问题定义：cron 到底给了任务什么环境

2.1 cron 守护进程的最小环境模型

cron 的实现有多个流派：Vixie cron（多数发行版的基础）、cronie（RHEL 系）、systemd-cron、busybox crond 等。它们在细节上有差异，但共享一个核心设计：不继承用户登录会话的环境变量，只保留极少数由守护进程显式设定的变量。以 Vixie cron 及其衍生实现为例，任务运行时通常只保证以下变量存在：

需要强调的是，上表是“保证存在”的集合，而非“完整环境”。不同实现还会注入 LANG、TZ 等变量，但取值往往来自守护进程启动时的环境，而非任务所有者登录时的环境。这意味着，即便同一台机器上两个用户的 .bashrc 配置不同，cron 任务看到的 LANG 也可能一致——因为它是从守护进程继承的。

本文评述：很多“cron 不执行”的讨论停留在“PATH 要写全”这一条经验上，但真正的机制是cron 刻意不加载任何 shell 初始化文件（/etc/profile、~/.bashrc、~/.bash_profile 都不会被读取），因为 cron 启动的是非交互、非登录 shell。理解这一点，才能解释为什么“在 .bashrc 里 export 的变量在 cron 里全部消失”，也才能理解为什么把命令改成绝对路径往往能立竿见影。

2.2 交互式 shell 与 cron 环境的差异矩阵

把差异结构化，有助于在排查时快速定位“我依赖了哪个不该依赖的东西”。下表按维度对比交互式登录 shell 与 cron 任务环境：

这张表是后文四步法的理论依据。PATH 差异对应第一步，工作目录与相对路径对应第二步，umask 与安全上下文对应第三步，而“无控制终端、输出被丢弃”则解释了为什么第四步必须依赖日志而不是“看起来有没有跑”。

2.3 问题定义：什么叫“到点不执行”

在进入排查之前，必须先精确界定故障现象，否则四步法会被误用。工程上“到点不执行”至少包含四种语义不同的状态：

1. 未调度：cron 守护进程没有在预定时间触发任务，日志中无对应记录。常见原因包括 crontab 语法错误、cron 服务未运行、时间字段理解偏差、任务被注释。
2. 已调度但命令未找到：日志显示任务已触发，但 shell 返回 127（command not found）。这是 PATH 问题的典型表现。
3. 已调度但执行失败：命令找到了，但脚本内部报错、权限不足、依赖缺失，返回非零退出码。
4. 已成功执行但“看起来没执行”：任务实际完成，但输出被丢弃、副作用不可见，或写到了预期之外的位置。

本文评述：这四种状态对应完全不同的排查入口。把“未调度”和“已调度但失败”混为一谈，是导致排查绕路的主要原因。因此四步法的第一步不是直接查 PATH，而是先用日志把状态从“未知”收敛到上述四类之一——这也是为什么本文把日志取证放在第四步却强调它应当“尽早看一眼”的原因：顺序是排查深度的顺序，不是信息获取的时间顺序。

三、四步排查法的总体顺序与判定逻辑

四步法的顺序不是随意的，而是按照“从最普遍、最廉价、最可能的原因，到最特殊、最昂贵、最少见的原因”排列，同时保证每一步的结论能缩小下一步的搜索空间。其判定逻辑可以概括为一条决策链：

任务是否被调度？
├─ 否 → 查 cron 服务状态、crontab 语法、时间字段、用户 crontab 是否生效
└─ 是 → 退出码/日志显示什么？
   ├─ 127 / command not found → 第一步 PATH
   ├─ 126 / permission denied → 第三步 权限
   ├─ 其他非零 → 第二步 绝对路径与依赖，再回到第三步
   └─ 0 但副作用缺失 → 第二步 相对路径/输出重定向，第四步 日志确认

这条决策链的关键在于：PATH 问题几乎总是表现为 127，而权限问题几乎总是表现为 126 或 EACCES。把退出码作为分流依据，比凭经验猜测要可靠得多。实际排查中，很多工程师跳过“看退出码”直接改 PATH，结果改完仍然失败，因为真正的问题是脚本没有执行权限。

笔者认为，四步法应当被理解为一个“假设检验流程”而非“检查清单”。每一步都在验证一个具体假设：第一步验证“命令能否被解析”，第二步验证“解析到的路径是否正确且完整”，第三步验证“当前身份是否有权执行与访问”，第四步验证“上述判断是否有证据支撑”。假设被证伪就进入下一步，被证实就停止——这比“四项都查一遍”更高效，也更不容易遗漏。

四、第一步：PATH 解析——先确认“找不到命令”还是“命令跑错”

4.1 PATH 在 cron 中的真实取值

要判断 PATH 是否是元凶，第一步是获取 cron 任务实际看到的 PATH，而不是在终端里 echo $PATH。最可靠的做法是在 crontab 中临时插入一条诊断任务：

* * * * * /usr/bin/env > /tmp/cron_env_$(date +\%s).txt 2>&1

注意 % 在 crontab 中有特殊含义（表示换行），必须转义为 \%。这条任务运行后，/tmp 下会出现一份完整的环境快照，其中 PATH 一行即为 cron 实际提供的值。在 Debian/Ubuntu 上通常形如 /usr/bin:/bin，在 RHEL 系上可能包含 /usr/local/bin，具体以实测为准。

本文评述：网上大量教程直接给出“在 crontab 顶部加 PATH=/usr/local/bin:/usr/bin:/bin”的模板，这在多数情况下有效，但它掩盖了一个事实——不同发行版、不同 cron 实现的默认 PATH 并不相同。直接抄模板可能引入新的不一致：模板里没有的目录，任务依然找不到；模板里多出的目录，可能让任务解析到非预期的同名二进制。更稳妥的做法是先实测、再显式声明。

4.2 区分“找不到命令”与“找到错误的命令”

PATH 问题有两种形态，危害程度不同。第一种是解析失败：命令不在任何 PATH 目录中，shell 返回 127，日志明确。第二种更隐蔽，是解析到错误版本：例如系统同时存在 /usr/bin/python3（3.9）与 /usr/local/bin/python3（3.12），交互式 shell 因 PATH 顺序先命中后者，cron 却命中前者，脚本因语法或依赖不兼容而失败，但退出码不是 127，排查时容易被误判为“脚本逻辑问题”。

判定方法是在诊断任务中同时记录命令解析结果：

* * * * * { echo "PATH=$PATH"; command -v python3; command -v node; } > /tmp/cron_which.txt 2>&1

把这份输出与交互式 shell 中的 command -v 结果对比，就能立刻看出是“找不到”还是“找错了”。如果是后者，仅补 PATH 不够，还需要在脚本内固定解释器版本，或使用虚拟环境/容器隔离。

4.3 修复策略：显式声明优于隐式继承

确认 PATH 是原因后，修复有三档，按侵入性从低到高排列：

• crontab 级：在 crontab 顶部写 PATH=/usr/local/bin:/usr/bin:/bin，对该用户所有任务生效。优点是集中，缺点是影响面大，可能改变其他任务的行为。
• 任务级：在单条任务的命令前内联赋值，如 PATH=/opt/app/bin:/usr/bin:/bin /opt/app/run.sh。优点是隔离，缺点是冗长。
• 脚本级：在脚本开头 export PATH=/opt/app/bin:$PATH。这是最推荐的做法，因为脚本自带环境声明，无论被 cron、systemd 还是人工调用都一致。

笔者认为，脚本级声明是唯一能同时解决“cron 环境”和“未来迁移到其他调度器”的方案。crontab 级和任务级修复都依赖调度器本身，一旦任务迁移到 systemd timer 或 Kubernetes CronJob，环境假设又要重新对齐。把环境声明下沉到脚本，等于把契约写进了代码，可移植性最好。

延伸阅读：Vixie cron 的 man 手册对 crontab 环境变量有明确说明，可作为权威参考（man7.org crontab(5)）；Red Hat 的解决方案文档也系统整理了 cron 环境问题（Red Hat Solution 24264）。

五、第二步：绝对路径——从命令到脚本到解释器到数据文件

5.1 绝对路径的四个层次

很多工程师把“用绝对路径”理解为“命令前加 /usr/bin/”，这远远不够。一个 cron 任务从触发到完成，涉及四层路径解析，任何一层用了相对路径都可能失败：

本文评述：第四层最容易被忽视。很多脚本在交互式 shell 中运行正常，是因为用户当时的工作目录恰好是项目根目录；cron 把工作目录设为 $HOME 后，脚本里的 ./config/app.yaml 就指向了不存在的位置。这类故障的退出码可能是 0（如果脚本没有检查文件存在性），表现为“执行了但没效果”，极难排查。

5.2 工作目录的显式设定

cron 任务的工作目录来自 passwd 中的 home 字段，而非 crontab 文件所在目录。要消除这一不确定性，有两种做法：

# 做法一：在命令中先 cd
0 2 * * * cd /opt/app && /opt/app/bin/backup.sh

# 做法二：在脚本内 cd 到脚本所在目录（更稳健）
#!/bin/bash
set -euo pipefail
SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
cd "$SCRIPT_DIR/.."

做法二的优势在于脚本自带定位逻辑，不依赖调用方。注意 set -euo pipefail 会让脚本在任一命令失败时立即退出，避免错误被吞掉——这与 cron 的静默特性形成互补，是提升可观测性的低成本手段。

5.3 解释器与 shebang 的陷阱

#!/usr/bin/env bash 是社区推荐写法，因为它能在不同系统上找到 bash。但在 cron 场景下，它把解释器解析交给了 PATH，等于把第一步的问题引入了第二步。如果 cron 的 PATH 不含 bash 所在目录（极少见但可能，例如自定义最小镜像），脚本会以 /usr/bin/env: bash: No such file or directory 失败。对于生产环境的关键任务，本文建议使用绝对 shebang（如 #!/bin/bash），并在部署时校验目标路径存在。

另一个常见陷阱是脚本使用了 CRLF 换行（在 Windows 上编辑后上传）。此时 shebang 行实际是 #!/bin/bash\r，内核会尝试执行名为 /bin/bash\r 的解释器，报错信息往往含糊。用 file script.sh 或 cat -A 可以快速识别。

六、第三步：权限边界——用户、umask、SELinux 与目录可达性

6.1 执行身份与文件权限

cron 任务以 crontab 所有者的身份运行。这意味着两件事：第一，任务能访问的资源受该用户权限约束；第二，sudo 在 cron 中通常不可用（因为没有 TTY，且 sudoers 默认 requiretty）。判定权限问题的最直接证据是退出码 126（permission denied）或日志中的 EACCES。

需要检查的权限点不止脚本本身，还包括：脚本所在目录的执行位（x）、脚本内调用的二进制、脚本读写的文件与目录、以及脚本依赖的配置文件。一个典型误判是：脚本有 chmod 755，但所在目录是 700 且属主是 root，普通用户 cron 任务依然无法进入该目录执行脚本。目录的 x 位是“可穿越”权限，常被忽略。

本文评述：权限排查应当遵循“从外到内”的顺序——先确认任务身份能否穿越到脚本路径（目录 x 位），再确认能否读取脚本（r 位），再确认能否执行（x 位），最后确认脚本内访问的资源是否可读写。反过来查容易在脚本内部绕圈，因为脚本本身的权限往往是最先被检查、也最容易被修好的。

6.2 umask 与文件创建行为

umask 决定新建文件的默认权限。cron 任务的 umask 继承自守护进程，常见值为 022，但并非保证。如果脚本创建的文件需要被其他进程读取，而 umask 是 077，文件权限会变成 600，导致下游读取失败——这类故障表现为“任务成功但下游报错”，与“不执行”现象不同，但根因同属环境契约断裂。

在 crontab 中显式设定 umask 是可行的：

# 注意：并非所有 cron 实现都支持在 crontab 中设置 umask
# 更可移植的做法是在脚本内设置
umask 022

由于不同 cron 实现对 crontab 内 umask 的支持不一致，本文建议统一在脚本内设置，并在脚本注释中说明原因，避免后续维护者误删。

6.3 强制访问控制：SELinux 与 AppArmor

在启用 SELinux 的 RHEL/CentOS 系系统上，cron 任务还受安全上下文约束。cron 守护进程以 system_u:system_r:crond_t 运行，任务继承该域。如果脚本需要访问被标记为其他类型的文件（例如用户家目录下的自定义类型），即使传统权限允许，SELinux 也可能拒绝，并在 /var/log/audit/audit.log 中留下 AVC 拒绝记录。

判定方法是检查审计日志：

ausearch -m avc -ts recent
# 或
grep AVC /var/log/audit/audit.log | tail -20

如果确认是 SELinux 导致，修复方式包括调整文件上下文（semanage fcontext + restorecon）或编写自定义策略模块。直接 setenforce 0 关闭 SELinux 是极不推荐的做法，会削弱系统整体安全性。AppArmor 在 Ubuntu/Debian 上扮演类似角色，检查入口是 dmesg | grep -i apparmor 或 journalctl -k | grep apparmor。

延伸阅读：SELinux 官方文档对 crond 域有专门说明（Red Hat SELinux 指南）；AppArmor 的 cron 配置文件通常位于 /etc/apparmor.d/usr.sbin.cron，可直接审阅。

七、第四步：cron 日志取证——从“没执行”到“执行失败”

7.1 日志在哪里

cron 日志的位置因发行版和日志系统而异，这是排查中最容易卡住的一环。常见位置如下：

如果日志中完全没有任务触发记录，说明问题在“未调度”层面，应检查 cron 服务状态（systemctl status cron 或 systemctl status crond）、crontab 是否被正确安装（crontab -l）、以及 /etc/cron.allow 与 /etc/cron.deny 是否限制了该用户。

7.2 让日志“说人话”

cron 默认只记录“任务已触发”这一事实，不记录命令输出。要获得失败原因，必须在任务中显式重定向输出：

0 2 * * * /opt/app/bin/backup.sh >> /var/log/backup.log 2>&1

更规范的做法是让脚本自己管理日志，并记录退出码与关键上下文：

#!/bin/bash
set -euo pipefail
LOG=/var/log/backup.log
exec >> "$LOG" 2>&1
echo "[$(date -Is)] start pid=$$ user=$(id -un) pwd=$(pwd) path=$PATH"
trap 'echo "[$(date -Is)] exit code=$?"' EXIT
# ... 业务逻辑 ...

这段模板的价值在于：它把 cron 排查最需要的四个上下文（时间、用户、工作目录、PATH）在每次执行时固化到日志里。下次再出现“不执行”，直接看日志就能排除大部分环境假设，而不必重新做诊断任务。

本文评述：日志取证常被当作“最后一步”，但从信息论角度看，它应当是贯穿四步的证据链。第一步的 PATH 实测、第二步的路径解析、第三步的权限判定，最终都要落到日志里的退出码和错误信息上。把日志放在第四步，是因为它需要前三步提供“该看什么”的上下文；但在实际操作中，先扫一眼日志再决定从哪步深入，往往是更高效的路径。

八、关键案例与数据：四类典型故障的分布与复现

8.1 案例一：PATH 缺失导致 127

某数据同步任务在 crontab 中写为 0 3 * * * sync_tool --src /data --dst /backup，其中 sync_tool 安装在 /usr/local/bin。手动执行正常，cron 中失败。日志显示 /bin/sh: sync_tool: command not found，退出码 127。诊断任务确认 cron 的 PATH 为 /usr/bin:/bin，不含 /usr/local/bin。修复：在脚本内 export PATH=/usr/local/bin:$PATH，并将 crontab 改为调用包装脚本。

8.2 案例二：相对路径导致“成功但无效果”

某报表脚本读取 ./conf/report.yaml，在项目目录下手动执行正常。cron 中任务返回 0，但报表未生成。原因是 cron 工作目录为 /root，脚本找不到配置文件后走了“使用默认配置”的分支，静默完成。修复：脚本内 cd "$(dirname "$0")/.."，并对配置文件缺失做显式报错。

8.3 案例三：目录 x 位缺失导致 126

某运维将脚本放在 /root/scripts/，属主 root，目录权限 700，脚本权限 755。普通用户 crontab 调用时返回 126。日志显示 Permission denied。修复：将脚本移至 /opt/app/bin/，目录权限 755，属主 root，脚本 755，普通用户可穿越、可执行、不可写。

8.4 案例四：SELinux 拒绝导致静默失败

某 CentOS 系统上，cron 任务需要读取 /home/app/data/ 下的文件。传统权限为 755/644，用户可读，但任务失败。审计日志出现 avc: denied { read } for ... scontext=system_u:system_r:crond_t。修复：为该目录设置合适的 SELinux 类型（如 httpd_sys_content_t 或自定义类型），并 restorecon -Rv 应用。

关于四类故障的分布，目前缺乏覆盖全行业的权威统计。本文不虚构比例数据，仅指出一个可验证的定性结论：在公开的技术问答与厂商知识库中，PATH 与相对路径类问题占据 cron 相关提问的多数，权限类次之，SELinux 类最少但排查成本最高（来源：Stack Overflow cron 标签下的高票问题分布，以及 Red Hat、Ubuntu 官方知识库的 cron 条目；具体计数随检索时间变化，此处不给出固定数值）。

本文评述：案例的价值不在于“记住结论”，而在于识别每类故障的可观测信号——127 指向 PATH，126 指向权限，退出码 0 但副作用缺失指向相对路径或静默分支，而传统权限正常却失败则指向强制访问控制。把信号与根因建立映射，比背诵排查清单更可持续。

九、对比与局限：容器、systemd timer 与分布式调度

9.1 容器化环境下的 cron

在容器中运行 cron 会引入新的变量。容器通常只有一个前台进程，cron 需要以守护进程方式启动，常见做法是用 supervisord、s6-overlay 或在 entrypoint 中后台启动。此时 cron 的环境继承自容器启动时的环境，可能包含编排平台注入的变量，也可能完全为空（取决于镜像的 ENV 设置）。此外，容器内的 PID 1 语义、日志采集方式（stdout vs 文件）、以及只读根文件系统都会影响任务行为。

本文评述：容器场景下，四步法的顺序仍然成立，但“日志”一步的形态变了——cron 日志可能不在 /var/log，而在容器运行时收集的 stdout 中。因此排查前应先确认日志出口，否则会在“日志为空”上浪费大量时间。另一个常见误区是把宿主机的 crontab 经验直接套用到容器，忽略了容器内用户、PATH、时区都可能不同。

9.2 systemd timer 的差异

systemd timer 是 cron 的现代替代方案之一，其环境模型与 cron 有本质区别：timer 触发的 service 默认继承 systemd 的环境（systemctl show-environment 可查），并可通过 Environment=、EnvironmentFile= 显式声明；工作目录由 WorkingDirectory= 指定；日志默认进入 journal，可用 journalctl -u 查看。这些机制让环境契约更容易被显式化，但也意味着从 cron 迁移时需要重写环境声明。

本文评述：systemd timer 并没有“消灭”环境契约问题，而是把契约从隐式变成了显式。如果迁移时只是把命令行照搬进 ExecStart=，而不声明环境与工作目录，同样会遇到“手动能跑、调度不跑”。因此四步法的思维仍然适用，只是每一步的检查对象从 crontab 变成了 unit 文件。

9.3 分布式调度器的边界

Kubernetes CronJob、Airflow、XXL-JOB 等分布式调度器把任务执行下沉到容器或工作节点，环境由镜像和 Pod 模板定义。这类系统的优势是环境可版本化、可复现，但代价是排查链路变长：任务不执行可能是调度器没触发、可能是 Pod 调度失败、可能是镜像拉取失败、可能是容器内命令失败。四步法在这里需要扩展为“调度层—编排层—容器层—应用层”四层，但每一层的核心问题依然是“环境契约是否对齐”。

十、工程化改进：把四步法固化为可观测能力

10.1 任务模板标准化

与其每次故障后临时排查，不如在任务创建时就消除大部分环境不确定性。一个可复用的 cron 任务模板应包含：绝对 shebang、set -euo pipefail、显式 PATH、显式工作目录、统一日志出口、退出码记录、以及关键上下文打印。把这些固化到团队的任务脚手架中，新任务默认继承，能从源头减少 PATH 与相对路径类故障。

10.2 健康检查与告警

cron 的静默特性意味着“不执行”不会主动告警。可行的改进是引入心跳机制：任务每次成功执行后写入一个时间戳文件或调用健康检查端点，外部监控系统检查该时间戳的新鲜度，超过阈值即告警。这比依赖 cron 日志更可靠，因为日志可能因轮转、权限或日志系统故障而丢失。

# 任务末尾写入心跳
date +%s > /var/lib/heartbeat/backup.ts
# 监控侧检查
now=$(date +%s); last=$(cat /var/lib/heartbeat/backup.ts)
[ $((now - last)) -gt 90000 ] && echo "backup heartbeat stale"

10.3 从“排查”到“预防”

笔者认为，四步法的终极价值不是让人更擅长排查，而是让人不需要排查。当任务模板强制显式声明环境、当心跳监控覆盖所有关键任务、当日志模板自动记录上下文，PATH、绝对路径、权限这三类问题在创建阶段就被消除了，剩下的只有日志取证用于确认与审计。这才是工程化的方向：把隐式契约变成显式契约，把事后排查变成事前约束。

延伸阅读：cron 与 systemd timer 的对比可参考 systemd 官方文档（systemd.timer(5)）；Kubernetes CronJob 的环境与日志语义见官方文档（Kubernetes CronJob）。

十一、结论与展望

crontab 到点不执行，表面上是“命令没跑”，实质上是执行环境契约断裂。本文以这一主线贯穿全文，把排查拆成 PATH 解析、绝对路径、权限边界、日志取证四步，并给出每一步的判定依据与修复策略。四步法的顺序遵循“从普遍到特殊、从廉价到昂贵”的原则，以退出码作为分流信号，以日志作为证据链，避免在错误的方向上反复试错。

展望未来，调度技术正在从“单机 cron”向“声明式调度”演进。systemd timer 把环境与依赖显式化，容器与分布式调度器把环境版本化，这些都在降低环境契约断裂的概率。但只要任务仍然运行在“与编写者不同的环境”中，契约对齐就仍是核心问题。本文评述：掌握四步法不是为了记住四个检查项，而是为了建立一种思维——任何“手动能跑、调度不跑”的现象，都应先问“两个环境差在哪里”，再问“哪个差异导致了当前症状”。这种思维可以迁移到 CI/CD、容器编排、Serverless 等更广泛的场景，其价值远超 cron 本身。

主要参考文献