我试图在后台运行 srun 的 slurm 作业。不幸的是，现在由于我必须通过 docker 运行事情，使用 sbatch 有点烦人，所以我试图找出是否可以一起避免这一切。
根据我的观察，每当我跑步时，说：
srun docker image my_job_script.py
并关闭我运行命令的窗口（以避免接收所有打印语句）并打开另一个终端窗口以查看命令是否仍在运行，似乎我的运行脚本由于某种原因被取消或其他原因。由于它不是通过 sbatch 它不会向我发送带有错误日志的文件（据我所知）所以我不知道它为什么关闭。
我也试过：
srun docker image my_job_script.py &
在终端中将控制权交还给我。不幸的是，如果我这样做，它仍然会继续在我的终端屏幕上打印东西，这是我试图避免的。
本质上，我通过 ssh 登录到远程计算机，然后执行 srun 命令，但似乎如果我终止 ssh 连接的通信，则 srun 命令会自动终止。有没有办法阻止这种情况？
理想情况下，我想基本上发送脚本以运行并且不会以任何原因取消它，除非我取消它scancel并且它不应该打印到我的屏幕上。所以我理想的解决方案是：
- 即使我退出 ssh 会话，也要继续运行 srun 脚本
- 即使关闭我发送命令的窗口，也继续运行我的 srun 脚本
- 继续运行我的 srun 脚本，让我离开 srun 会话，而不是打印到我的屏幕上（即基本上运行到后台）
这将是我的想法解决方案。
对于想知道 sbatch 问题的好奇人群，我希望能够做到（这是理想的解决方案）：
sbatch docker image my_job_script.py
但是，正如人们知道的那样，它不起作用，因为 sbatch 接收到的命令 docker 不是“批处理”脚本。本质上一个简单的解决方案（这对我的情况并不适用）是将 docker 命令包装在批处理脚本中：
#!/usr/bin/sh
docker image my_job_script.py
不幸的是，我实际上正在使用我的批处理脚本来编码我正在运行的任务的大量信息（有点像配置文件）。所以这样做可能会影响我所做的工作，因为它们的基础文件正在改变。通过将作业直接发送到 sbatch 可以避免这种情况，因为它实际上创建了批处理脚本的副本（如本问题所述：在运行期间更改发送到 sbatch 的 bash 脚本是个坏主意？）。所以我的问题的真正解决方案是让我的批处理脚本包含我的脚本所需的所有信息，然后以某种方式在 python 中调用 docker 并同时传递所有信息。不幸的是，其中一些信息是函数指针和对象，所以我什至不清楚如何将这样的东西传递给在 python 中运行的 docker 命令。
或者也许能够直接运行 docker 到 sbatch 而不是使用批处理脚本也可以解决问题。