EC2实例后台运行TensorFlow脚本遇ModuleNotFoundError求助

这问题我之前在EC2上折腾conda环境时也碰到过！核心问题其实是screen/tmux会话没有正确继承conda的环境变量，导致conda env list显示在tensorflow_p36环境，但实际调用的还是系统Python，自然找不到tensorflow包。给你几个靠谱的解决办法：

方法1：在会话内显式激活环境并验证Python路径 #

这是最稳妥的方式，确保每一步都走对：

• 新建screen/tmux会话：

  # screen的方式
  screen -S tf_training
  # 或者tmux的方式
  tmux new -s tf_training
  

• 在会话里手动激活虚拟环境（不要依赖自动加载）：

  # 旧版conda用这个
  source activate tensorflow_p36
  # conda 4.4+版本用这个
  conda activate tensorflow_p36
  

• 立刻验证当前Python路径，确认是虚拟环境的：

  which python
  

  正常应该输出类似/home/ec2-user/anaconda3/envs/tensorflow_p36/bin/python，而不是系统的/usr/bin/python
• 最后用这个Python运行你的脚本：

  python your_training_script.py
  

  嫌麻烦的话直接用绝对路径更保险：

  /home/ec2-user/anaconda3/envs/tensorflow_p36/bin/python your_training_script.py
  

方法2：让screen/tmux继承conda的环境配置 #

有时候screen/tmux启动时不会加载你的shell配置文件（比如.bashrc或.bash_profile），而conda的初始化代码通常写在这些文件里。可以这样解决：

• 对于screen，启动时强制用登录shell加载配置：

  screen -S tf_training -c <(echo 'shell -$SHELL')
  

• 对于tmux，要么在启动会话前确保conda已经初始化，要么在会话内重新初始化：

  conda init bash
  source ~/.bashrc
  

  之后再激活tensorflow_p36环境，就能正常调用虚拟环境的Python了。

方法3：用nohup替代screen/tmux（简单直接） #

如果不想折腾screen/tmux的环境继承问题，用nohup直接后台运行也能达到目的：

• 先激活虚拟环境：

  source activate tensorflow_p36
  

• 用nohup启动脚本，把输出定向到日志文件：

  nohup python your_training_script.py > training_log.log 2>&1 &
  

• 关闭SSH后脚本会继续运行，你之后登录可以用tail -f training_log.log查看实时输出，用ps aux | grep your_training_script.py检查进程状态。

额外排查点：脚本的shebang行 #

如果你的脚本开头写了#!/usr/bin/env python，这会强制调用系统默认的Python，哪怕你在虚拟环境里。解决办法是把shebang改成虚拟环境的Python路径：

#!/home/ec2-user/anaconda3/envs/tensorflow_p36/bin/python

然后给脚本加执行权限：

chmod +x your_training_script.py

之后直接运行./your_training_script.py就会用虚拟环境的Python了。

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