Linux cron补齐定时任务缺失的环境变量的实现方法

同一条命令在终端里能运行，放进 Linux cron 后却提示“找不到命令”“配置文件不存在”或输出为空，通常不是程序突然坏了，而是启动它的环境变了。cron 运行任务时不会把交互式登录 Shell 的完整环境原样带过来，尤其容易缺少 PATH、PWD、语言设置和应用自定义变量。

最稳的做法是：在 crontab 顶部声明任务真正需要的最小变量，在脚本里固定工作目录并使用绝对路径，再把标准错误写入绝对日志文件。不要直接复制整份登录环境。

crontab 文档明确说明，cron 会自动设置 SHELL、HOME 和 LOGNAME；HOME、SHELL 可以覆盖，LOGNAME 不能覆盖。默认命令由 /bin/sh 执行。因此，“我的终端里已经 export 过变量”不能作为定时任务可用的依据。

先给结论：显式声明最小环境，比复制登录 Shell 更稳

先把命令依赖拆成四类：执行器需要的 PATH，程序需要的应用目录和配置文件，文件操作需要的工作目录，排错需要的日志位置。用户级 crontab 可以把环境设置写在命令前面，变量行必须独占一行；不要把注释放在变量或命令的末尾。

# 使用明确的 shell，避免依赖系统默认值
SHELL=/bin/sh
# 只声明任务会用到的可执行目录
PATH=/usr/local/bin:/usr/bin:/bin
# 给脚本固定应用边界和配置入口
APP_HOME=/srv/report-job
CONFIG_FILE=/etc/report-job/job.conf
LOG_DIR=/var/log/report-job

# 用绝对路径启动包装脚本，并保存标准输出和错误
15 2 * * * /srv/report-job/bin/run-report.sh >> /var/log/report-job/cron.log 2>&1

这里的关键不是变量越多越好，而是让依赖可读、可审计。不要写成 source ~/.profile && ... 来“恢复一切”：profile 可能包含交互判断、别名、输出语句或不同用户的路径，反而会让 cron 行为不稳定。任务确实需要某个变量时，就把它写出来。

用包装脚本固定工作目录、参数和失败日志

crontab 行适合描述“什么时候启动谁”，不适合承载复杂的目录切换、参数拼接和错误处理。把这些动作放入脚本后，环境变量的来源就集中在一个地方，也更容易在手工和定时两种场景下复现。

#!/bin/sh
# 遇到未处理错误或未定义变量时立即退出，避免继续写出半成品
set -eu

# cron 的当前目录不可假定，先切到应用目录
APP_HOME=${APP_HOME:-/srv/report-job}
CONFIG_FILE=${CONFIG_FILE:-/etc/report-job/job.conf}
LOG_DIR=${LOG_DIR:-/var/log/report-job}
PATH=/usr/local/bin:/usr/bin:/bin
export APP_HOME CONFIG_FILE LOG_DIR PATH
cd "$APP_HOME"

# 用绝对路径执行程序，参数和配置入口保持显式
/usr/bin/python3 "$APP_HOME/bin/report.py" --config "$CONFIG_FILE"

set -u 会把拼写错误的变量尽早暴露出来；默认值只适合明确安全的本机路径，敏感凭据不应硬编码在 crontab 或日志中。脚本没有假设 PWD，也没有依赖用户的别名或函数。若程序需要特定语言环境，可以再显式导出 LANG 或 LC_ALL，但先确认目标系统确实安装了对应 locale。

为什么交互终端能跑，cron 却找不到命令

交互终端通常会读取登录配置，拥有更长的 PATH、当前目录、别名和函数；cron 只按自己的环境启动命令。即便 HOME 一样，PWD、PATH 和 profile 是否加载也可能不同。排查时不要猜，先把证据打印到独立日志。

#!/bin/sh
# 将 cron 看到的关键上下文写入绝对路径日志
set -u
OUT=/tmp/cron-env-check.log
{
  echo "--- environment ---"
  printf 'HOME=%s\n' "${HOME-}"
  printf 'PATH=%s\n' "${PATH-}"
  printf 'PWD=%s\n' "${PWD-}"
  printf 'SHELL=%s\n' "${SHELL-}"
  echo "--- command lookup ---"
  command -v python3 || true
  pwd
} >"$OUT" 2>&1

还可以用 env -i 模拟近似的干净环境，再只补入你认为必要的变量：

# 用干净环境复现，不继承当前终端的变量
env -i HOME=/srv/report-job \
  PATH=/usr/local/bin:/usr/bin:/bin \
  /srv/report-job/bin/run-report.sh

如果这样运行失败，说明脚本仍依赖未声明的环境或工作目录；如果干净环境能运行，再检查 cron 表达式、用户权限和日志重定向。command -v 找不到程序时，优先补 PATH 或改用绝对路径，不要仅在当前终端执行一次 export。

用户 crontab 与 /etc/cron.d 的字段不要混用

编辑自己的任务时，格式是五个时间字段加命令；系统级的 /etc/cron.d 条目通常还要在时间字段后写用户名，再写命令。把系统任务格式直接粘到用户 crontab，会让用户名被当作命令的一部分。

# 用户 crontab：五个时间字段后直接是命令
15 2 * * * /srv/report-job/bin/run-report.sh

# /etc/cron.d/report-job：时间字段后增加运行用户
15 2 * * * report /srv/report-job/bin/run-report.sh

变量行要写成独立的 NAME=value，命令最后保留换行；cron 文档还提醒，未转义的百分号在命令中有特殊含义，生成日期格式时要特别小心。改完后，先用目标用户手工执行包装脚本，再查看 cron 自身日志和任务日志，确认“启动了”“找到了配置”“程序返回成功”是三个分别成立的事实。

常见边界与速查

• 缺少命令：显式设置 PATH，或使用程序绝对路径。
• 配置找不到：不要使用相对路径，固定 CONFIG_FILE 或在脚本中先 cd。
• 写文件失败：检查 cron 运行用户对日志、临时目录和应用目录的权限。
• 时间不符合预期：确认 cron 表达式和时区设置，不要把环境变量问题与调度表达式混为一谈。

简而言之，cron 任务的可靠性来自“显式环境 + 绝对路径 + 固定工作目录 + 可读日志”。变量越少越容易维护，但每个实际依赖都应该在 crontab 或包装脚本中留下清楚来源。

相关问题

cron 一定不会设置 HOME 吗？不一定。常见 cron 实现会按 crontab 所有者设置 HOME，但不同实现和运行方式仍应以目标系统文档为准；应用若依赖 HOME 下的配置，最好把入口显式化。

可以直接把当前终端的 env 全部写进 crontab 吗？不建议。完整环境可能带入临时凭据、交互设置和无关路径，既难审计，也可能造成权限或复现问题。