是否可以使用 SRUN 而不是 SBATCH 在后台運行 SLURM 作業？

Question

我試圖在后台運行帶有 srun 的 slurm 作業。 不幸的是，現在由於我必須通過 docker 運行它，所以使用 sbatch 有點煩人所以我試圖找出是否可以一起避免它。

根據我的觀察，每當我運行 srun 時，都會說：

srun docker image my_job_script.py

並關閉我運行命令的 window（以避免接收所有打印語句）並打開另一個終端 window 以查看命令是否仍在運行，似乎我的運行腳本由於某種原因被取消或其他原因。 由於它不是通過 sbatch，它不會向我發送帶有錯誤日志的文件（據我所知），所以我不知道它為什么關閉。

我也試過：

srun docker image my_job_script.py &

在終端中將控制權還給我。 不幸的是，如果我這樣做，它仍然會繼續將內容打印到我的終端屏幕上，而我正試圖避免這種情況。

本質上，我通過 ssh 登錄到遠程計算機，然后執行 srun 命令，但似乎如果我終止我的 ssh 連接的通信，srun 命令會自動終止。 有辦法阻止這種情況嗎？

理想情況下，我基本上希望發送腳本運行並且不會因為任何原因取消它，除非我通過scancel取消它並且它不應該打印到我的屏幕上。 所以我理想的解決方案是：

1. 即使我退出 ssh session 也繼續運行 srun 腳本
2. 即使從我發送命令的地方關閉 window，也要繼續運行我的 srun 腳本
3. 繼續運行我的 srun 腳本，讓我離開 srun session 並且不打印到我的屏幕（即基本上運行到后台）

這將是我的想法解決方案。

---

對於想知道 sbatch 問題的好奇人群，我希望能夠做到（這是理想的解決方案）：

sbatch docker image my_job_script.py

但是，正如人們所知，它不起作用，因為 sbatch 收到命令 docker，這不是“批處理”腳本。 本質上，一個簡單的解決方案（對我的情況並不適用）是將 docker 命令包裝在批處理腳本中：

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

不幸的是，我實際上正在使用我的批處理腳本來編碼我正在運行的任務的大量信息（有點像配置文件）。 所以這樣做可能會影響我所做的工作，因為它們的基礎文件正在發生變化。 通過將作業直接發送到 sbatch 可以避免這種情況，因為它實際上創建了批處理腳本的副本（如本問題所述： Changing the bash script sent to slurm during run a bad idea? ）。 所以我的問題的真正解決方案是讓我的批處理腳本包含我的腳本所需的所有信息，然后以某種方式在 python 中調用 docker 並同時將所有信息傳遞給它。 不幸的是，一些信息是 function 指針和對象，所以我什至不清楚如何將這樣的東西傳遞給在 python 中運行的 docker 命令。

---

或者也許能夠直接運行 docker 到 sbatch 而不是使用批處理腳本也可以解決問題。

Answer 1

輸出可以使用選項-o stdout重定向， -e用於stderr 。

因此，可以在后台啟動作業並重定向輸出：

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

Answer 2

另一種方法是使用像tmux或屏幕這樣的終端多路復用器。

例如，創建一個新的tmux窗口類型tmux 。 在該窗口中，使用srun和腳本。 從那里，您可以分離tmux窗口，該窗口將您返回到主shell，以便您可以開展其他業務，或者您可以完全注銷。 如果要簽入腳本，只需重新連接到tmux窗口即可。 有關如何分離和重新連接操作系統的信息，請參閱文檔tmux -h 。

使用-o或-e任何輸出重定向仍將使用此技術，您可以在不同的tmux窗口中同時運行多個srun命令。 我發現這種方法很有用，特別是在開發需要數小時才能運行的腳本時。

Answer 3

我也想知道這一點，因為sbatch和srun之間的差異不是很清楚地解釋或動機。 我查看了代碼，發現：

sbatch

sbatch幾乎只是將 shell 腳本發送到 controller，告訴它運行它然后退出。 它不需要在作業進行時繼續運行。 它確實有一個--wait選項可以保持運行直到作業完成，但它所做的只是每 2 秒輪詢一次 controller 以詢問它。

sbatch無法跨多個節點運行作業 - 代碼根本不在sbatch.c中。 sbatch不是根據srun實現的，這是完全不同的事情。

此外，它的參數必須是 shell 腳本。 有點奇怪的限制，但它確實有一個--wrap選項，因此它可以自動為您將真實程序包裝在 shell 腳本中。 祝所有 escaping 正確無誤！

srun

srun更像是一個 MPI 運行程序。 它直接在許多節點上啟動任務（默認情況下每個節點一個任務，但您可以使用--ntasks覆蓋它）。 它適用於 MPI，因此所有作業都將同時運行。 直到所有節點都有空閑時，它才會開始。

它必須在作業進行時保持運行。 您可以使用&將其發送到后台，但這仍然與sbatch不同。 如果您需要啟動一百萬srun ，您就會遇到問題。 一百萬sbatch應該（理論上）可以正常工作。

沒有辦法讓srun退出並讓作業繼續運行，就像sbatch 。 srun本身充當作業中所有節點的協調器，並更新作業狀態等，因此它需要在整個過程中運行。