Python脚本手动运行正常但Crontab执行异常，数据未全写入数据库

针对你遇到的「手动执行Python脚本正常，但crontab执行仅写入部分数据库数据」的问题，以下是常见原因和对应的解决办法：

1. 环境变量不匹配 #

crontab的执行环境和终端的环境变量差异很大，哪怕Python路径一致，脚本依赖的其他环境变量（比如数据库密码、系统PATH、虚拟环境变量）可能在crontab里缺失，导致部分逻辑执行失败。

• 解决：
  • 要么在crontab命令开头导入终端的环境配置，比如：00 07 * * 2-5 source /home/www-data/.bashrc && /usr/local/bin/python /full_path/script.py >> /full_path/file.txt 2>&1；
  • 要么直接在脚本里硬编码所有必要的环境变量（比如数据库连接参数），避免依赖系统环境。

2. 相对路径导致文件读取异常 #

如果脚本里用了相对路径读取数据源（比如./input.csv），手动执行时你是在脚本所在目录，路径没问题；但crontab的默认工作目录是www-data的家目录（通常是/var/www或/home/www-data），这时候相对路径指向的文件根本不是你要的那个，自然只能读到空数据或者部分错误数据。

• 解决：
  • 把脚本里所有文件路径（包括数据源、临时文件、日志文件）全改成绝对路径；
  • 或者在crontab里先切换到脚本目录再执行：00 07 * * 2-5 cd /full_path && /usr/local/bin/python script.py >> /full_path/file.txt 2>&1。

3. 数据库事务未提交或连接异常 #

手动执行时，数据库客户端可能默认自动提交事务，但crontab环境下可能没有这个配置；或者网络波动导致部分连接中断，脚本没处理异常就继续执行，只写入了成功的部分。

• 解决：
  • 检查脚本里的数据库操作，确保每次写入后都显式调用commit()（比如用psycopg2或MySQLdb时）；
  • 给数据库操作加异常捕获和重试逻辑，比如连接超时后重试3次，同时把错误信息写入日志；
  • 查看数据库的慢查询日志，确认是否有语句执行超时被终止。

4. 未捕获标准错误日志 #

你当前的crontab只重定向了标准输出，脚本执行时的错误信息（比如文件找不到、数据库报错）都被丢弃了，根本不知道哪里出问题。

• 解决：
  • 修改crontab配置，把标准错误也重定向到日志文件：00 07 * * 2-5 /usr/local/bin/python /full_path/script.py >> /full_path/file.txt 2>&1；
  • 执行完后查看/full_path/file.txt，里面的错误信息会直接告诉你问题所在。

5. 系统资源不足导致脚本中断 #

crontab执行时段可能系统负载高，脚本因为内存不足被OOM Killer杀掉，或者磁盘IO繁忙导致写入中断，只完成了部分数据处理。

• 解决：
  • 查看系统日志（比如/var/log/syslog），搜索www-data或你的脚本名，看是否有被终止的记录；
  • 优化脚本：分批读取文件和写入数据库，不要一次性把所有数据加载到内存；
  • 调整系统资源配置，比如给www-data用户增加内存配额。

快速验证步骤 #

1. 先修改crontab的日志重定向，加上2>&1，运行一次后查看日志；
2. 检查脚本里所有路径是否都是绝对路径；
3. 在脚本里加详细日志：每读取N条数据、每写入N条数据都记录到日志，定位是读取阶段还是写入阶段出问题。

内容的提问来源于stack exchange，提问作者rira