crontab 定时任务死活不跑，手动执行一模一样的命令却正常，一般卡在哪几个环节？

同一行命令，手动跑一切正常，进了 crontab 就没动静——问题几乎都出在"环境不一样"。cron 执行任务时是一个精简环境，和你坐在终端里的环境差异就是排查主线。按下面五个环节过，绝大多数能定位。

环节一：先确认 cron 到底有没有跑

别急着怀疑脚本，先看任务有没有被调度。查 cron 服务状态，再看系统日志里的 cron 记录，确认计划时刻有没有触发记录。有触发记录说明调度正常，问题在脚本环境；连记录都没有，看任务写在了哪个用户的 crontab 里、cron 服务有没有起来。

环节二：路径问题

手动执行时你处在某个目录里，脚本里的相对路径自然有效；cron 的工作目录是用户主目录，相对路径全部失灵。脚本里该用绝对路径的都用绝对路径，或者开头显式切换目录。

环节三：环境变量问题

cron 不会加载你的登录配置，终端里能用的命令别名、自定义环境变量、版本管理工具初始化出来的路径，在 cron 里统统不存在。命令写全路径，脚本开头自己把需要的变量设好。日志和输出记得显式重定向，否则报错信息无声消失，你连它死在哪都看不到。

# 示例：显式环境+全路径+输出落盘
MAILTO=""
17 2 * * * /bin/bash /opt/scripts/nightly.sh >> /var/log/nightly.log 2>&1

环节四：百分号与语法陷阱

crontab 行里百分号有特殊含义（会被当换行处理），命令里要原样输出百分号的得转义。还有时间字段写错（比如把"每周"写成"每月"）、以及列表里逗号后多出空格这类小语法坑，逐字段核对一遍。

环节五：权限与资源

任务用的账号对目标目录有没有写权限、脚本本身有没有执行位、密码类凭据是不是存在只在登录会话里可读的地方。再有一种隐蔽情况：任务其实跑了，但卡在等输入——脚本里某条命令在等待确认，cron 环境里没人应答，任务挂到超时。把脚本里所有交互提示去掉，做成无人值守模式。

一个调试技巧

排查期给任务加一行高频触发的测试项，几分钟跑一次最小化的脚本，改一次验证一次，比每次等到深夜验证快得多。定位之后删掉测试项，恢复正式计划。另外提一句存放位置：个人任务放 crontab 里，团队共用的任务建议放系统的定时任务目录，文件开头写明执行账号和 Shell，集中一处便于交接——不少"换了人就不跑"的排查，答案就藏在任务散落在谁的 crontab 里。

贵州诚鑫致达科技在服务器运维交接里给定时任务定了硬规矩：脚本一律自包含（绝对路径、自带环境、自带日志），部署时先在测试计划上验证一轮再挂正式时刻，把"手动正常、定时失灵"这类问题拦在上线前。

企业存储选型参考｜贵州诚鑫致达

做备份容灾一体机方案，群晖机型参考：DP7400 · DP520 · DP320。需要选型建议或上门评估，搜「诚鑫致达」即可找到我们。

服务区域｜贵州诚鑫致达

贵州群晖NAS、贵阳存储、数据备份、信创云盘或 IT 集成服务，可联系贵州诚鑫致达科技，服务范围覆盖贵州全省各市州。广西南宁企业存储与网络建设维护，本地化技术支持。