Linux下Cron运行Python脚本常见问题

Linux下cron执行Python脚本失败，绝大多数并非代码本身有误，而是因环境差异导致的“隐形陷阱”：cron默认PATH极窄、工作目录为根目录、不自动识别shell环境变量、不检查脚本执行权限，且日志默认丢失——只需四步即可破局：在crontab顶部显式声明完整PATH、用cd切换至脚本所在目录或全程使用绝对路径、chmod +x赋予脚本可执行权限、务必重定向stdout和stderr到可写日志文件。真正高效排错的关键，是放弃“在终端能跑就等于cron能跑”的直觉，转而用env | grep PATH比对环境、用绝对路径消除歧义、靠真实日志定位问题，而非凭猜测反复试错。

直接说结论：cron 执行 Python 脚本失败，90% 是因为路径写错、权限没给、或根本找不到 python 命令——不是脚本有问题，是 cron 根本没在你预期的环境里跑。

crontab 里调用 python 命令报 command not found

现象：日志里只有一行 /bin/sh: python: command not found，但你在终端敲 python --version 完全正常。

原因：cron 启动时只认默认 PATH=/usr/bin:/bin，而你的 python3 可能在 /usr/local/bin/python3，或 miniconda 在 ~/miniconda3/bin/python，这些都不在默认路径里。

解决办法（选其一，推荐第 2 种）：

• 在 crontab -e 文件顶部显式声明 PATH：

  PATH=/usr/local/bin:/usr/bin:/bin:/home/yourname/miniconda3/bin

• 直接在 crontab 行里用绝对路径调用：

  0 2 * * * /home/yourname/miniconda3/bin/python /home/yourname/scripts/backup.py

• 别信 which python3 输出——它是在你当前 shell 里查的，和 cron 环境不一致；用 env | grep PATH 对比真实差异更可靠

脚本里 open("config.json") 报 No such file or directory

现象：手动运行脚本没问题，cron 一跑就提示找不到配置文件、日志目录、数据库 dump 输出路径。

原因：cron 默认工作目录是 /，不是你家目录，也不是脚本所在目录。所有相对路径（./、../、config.json）全部失效；~ 和 $HOME 也为空（除非你在 crontab 里显式设了 HOME=）。

必须做这几件事：

• 脚本开头加 cd /home/yourname/project || exit 1 切到确定路径
• 所有文件操作用绝对路径：open("/home/yourname/project/config.json")，而不是 open("config.json")
• 输出日志也写绝对路径：0 2 * * * /path/to/script.py >> /var/log/myscript.log 2>&1

chmod +x 不做，脚本压根不会执行

现象：crontab -l 能看到任务，/var/log/cron 显示“executed”，但脚本里 print 或 touch 完全没反应。

原因：cron 不会帮你解释脚本内容，它只按「可执行文件」方式调用。Python 脚本没有 x 权限，就等同于一个普通文本文件——cron 会静默跳过。

确认并修复：

• 运行 ls -l /path/to/script.py，看有没有 -rwxr-xr-x 中的 x
• 补权限：chmod +x /path/to/script.py
• 如果脚本依赖其他文件（比如 data/ 目录），确保 cron 运行用户（如 yourname 或 root）对该目录有读写权限：chown yourname:yourname /path/to/data

日志重定向写错，等于没排错

现象：“不知道为啥没跑”“看不出哪错了”“邮件收不到”——其实 cron 默认把 stdout/stderr 交给本地邮件系统，而多数服务器根本没配 mail 服务。

最简验证方式就是强制重定向：

• 必须带 >> /path/to/log 2>&1，缺一不可：

  0 2 * * * /home/u/script.py >> /var/log/script.log 2>&1

• 2>&1 不能写成 2>1，少个 & 就变成写入名为 “1” 的文件
• 日志路径本身也要可写，建议先手动 touch /var/log/script.log && chown yourname:yourname /var/log/script.log
• 顺便打开系统级 cron 日志：sudo sed -i 's/^#*\(cron\.\*\)/\1/' /etc/rsyslog.conf，再 sudo systemctl restart rsyslog

真正卡住人的，往往不是某一行语法写错，而是 PATH、工作目录、权限、日志这四样里有两样没对上——它们互相掩盖错误，导致你改了 A 却发现 B 还在报错。每次改完，先 crontab -l 确认任务在列表里，再等一分钟看日志，比反复猜快得多。

本篇关于《Linux下Cron运行Python脚本常见问题》的介绍就到此结束啦，但是学无止境，想要了解学习更多关于文章的相关知识，请关注golang学习网公众号！