是否可以使用SRUN而不是SBATCH在后台运行SLURM作业?

时间:2017-02-10 18:39:46

标签: python slurm sbatch

我试图在后台运行slrm工作。不幸的是,现在由于我必须通过docker运行它有点烦恼使用sbatch所以我试图找出我是否可以一起避免它。

根据我的观察,每当我跑步时,说:

srun docker image my_job_script.py

并关闭我运行命令的窗口(以避免接收所有打印语句)并打开另一个终端窗口以查看该命令是否仍在运行,似乎我的运行脚本由于某种原因被取消或者其他什么。由于它没有通过sbatch它不会向我发送一个带有错误日志的文件(据我所知)所以我不知道为什么它会关闭。

我也尝试过:

srun docker image my_job_script.py &

在终端给我控制权。不幸的是,如果我这样做,它仍然会在我的终端屏幕上打印东西,我试图避免这种情况。

基本上,我通过ssh登录到远程计算机,然后执行srun命令,但似乎如果我终止ssh连接的通信,则会自动终止srun命令。有办法阻止这个吗?

理想情况下,我想基本上发送脚本来运行,不要因为任何原因而取消它,除非我通过scancel取消它并且它不应该打印到我的屏幕上。所以我理想的解决方案是:

  1. 即使我退出ssh会话也继续运行srun脚本
  2. 即使关闭我发送命令的窗口
  3. ,也要继续运行我的srun脚本
  4. 继续运行我的srun脚本让我离开srun会话而不打印到我的scree(即基本上跑到后台)
  5. 这将是我的想法解决方案。

    对于想要了解sbatch问题的好奇人群,我希望能够做到(这是理想的解决方案):

    sbatch docker image my_job_script.py
    

    然而,因为人们会知道它不起作用,因为sbatch收到了命令码头,这不是一个批量"脚本。基本上一个简单的解决方案(对我的案例来说真的不起作用)就是将docker命令包装在批处理脚本中:

    #!/usr/bin/sh
    docker image my_job_script.py
    

    不幸的是,我实际上正在使用我的批处理脚本来编码我正在运行的任务的大量信息(有点像配置文件)。这样做可能会影响我的工作,因为他们的基础文件正在发生变化。通过将作业直接发送到sbatch可以避免这种情况,因为它实际上创建了批处理脚本的副本(如本问题中所述:Changing the bash script sent to sbatch in slurm during run a bad idea?)。因此,我的问题的真正解决方案是实际让我的批处理脚本包含我的脚本所需的所有信息,然后以某种方式在python中调用docker并同时传递所有信息。不幸的是,一些信息是函数指针和对象,所以我甚至不清楚如何将这样的东西传递给在python中运行的docker命令。

    或者也许能够直接运行docker到sbatch而不是使用批处理脚本来解决问题。

2 个答案:

答案 0 :(得分:3)

输出可以使用选项 -o 标准输出 -e 重定向,用于 stderr

因此,可以在后台启动作业,并重定向输出:

$ srun -o file.out -e file.errr docker image my_job_script.py &

答案 1 :(得分:0)

另一种方法是使用tmuxscreen之类的终端多路复用器。

例如,创建一个新的tmux窗口类型tmux。在该窗口中,将srun与脚本一起使用。然后,您可以从此处分离tmux窗口,这将使您返回主外壳,以便进行其他业务,或者完全注销。当您要签入脚本时,只需重新附加到tmux窗口即可。有关如何在操作系统上分离和重新连接的信息,请参见文档tmux -h

使用-o-e进行的任何输出重定向仍然可以使用此技术,并且您可以在不同的tmux窗口中同时运行多个srun命令。我发现这种方法很有用,特别是在开发需要花费数小时才能运行的脚本时。