` 看 `Allow*`/`DefaultTime/MaxTime/State`/Features| 改到合適 partition（`-p`）、調整需求、移除不相容 `--constraint/--gres`|
| **BeginTime**| 設了延後啟動（`--begin=...`） | 手動排程到未來、或系統規則造成| `squeue -j
---
---
## Slurm srun 如何把環境變數帶到 worker 的 task process
> by gpt-5.2 (2025/12/30)
### Slurm `srun` 如何把環境變數帶到 worker 的 task process
在 Slurm 的執行模型裡，「環境變數的傳遞」不是 worker 端去讀 login pod 的環境，而是 **login pod 上的 `srun` 先把這次要傳的環境變數清單整理好**，再把它作為 **step 啟動參數的一部分**，透過 Slurm 的 RPC 送到執行端，最後由 `slurmstepd` 在 `execve()` 啟動 task 時把這份 env 注入到 process。
#### 一個更精準的端到端流程（login pod 執行 `srun`）
```text
(login pod)
你的 shell 環境
│
▼
srun 依 --export 規則，組出「這次 step 要用的環境變數清單」
│ （打包：包含你指定要傳的 key/value）
▼
(slurmctld / controller)
分配節點 + 協調建立 step（RPC 協調與狀態管理）
│
▼
(worker pod)
slurmd 收到 launch step/task 的請求
│
▼
slurmstepd (root) 建立 step、設定 cgroup/limits、準備執行環境
│
▼
execve() 啟動你的 task process（用你的 UID），並把那份 env 清單帶進去
```
這裡的**關鍵角色**就是：**`srun`（client）負責決定「要傳哪些環境變數」**；worker 端只是接收並在啟動 task 時使用。
---
### `--export` 的本質：決定「打包進 step 的 env 清單」
`--export` 影響的是 `srun`（或 `sbatch`/`salloc`）在提交 step/job 時，**要不要把目前 shell 的哪些環境變數，打包成一份 env list**。
常見直覺落差在於：
* 你在 login pod 的 shell 裡 `export FOO=bar`
**不等於** worker 端會「自己去讀」到這個變數
* 真正會被帶過去的是：`srun` **當下**依 `--export` 規則整理出的那一份清單
所以環境變數的傳遞是「一次性快照」：
* `srun` 打包當下的 env 清單 → 送出 → worker 啟動 task
* 之後 login 那邊再改 env，不會回頭影響已啟動的 step/task
---
### `slurmstepd` 與 task process 的環境：目標是 task，不是 stepd
在 worker pod 端，`slurmstepd`（通常是 root）負責把 step 的執行環境準備好，最後 `execve()` 啟動你的 task process（用你的 UID）。要注意兩個常被誤會的點：
1. **`--export` 的目標是「你的 task process」**
`slurmstepd` 自己（那個 root 的 daemon）不需要、也不一定會擁有你那份 `--export` 的 env。
2. **worker 端不會回去讀 login pod 的 env**
傳遞完全依賴 `srun` 當下打包的清單；不是動態同步。
---
### 在 worker 上驗證「task process 實際收到哪些 env」
最直接、最不會被 shell/啟動腳本誤導的方法，是看該 task process 的 `/proc/
---
---
## [srun] `--container-image` 路徑解析
> `global.anthropic.claude-opus-4-6-v1` (2026/04/27)
### Q: `srun --container-image=/mnt/data/ubuntu+24.04.sqsh` 這個路徑是在 login node 還是 worker node 上解析的？
**A: Worker node。** 檔案必須存在於執行任務的 compute node 上，不是你下 `srun` 指令的 login node。
---
### Q: 為什麼是 worker node？
**A:** NVIDIA Pyxis（提供 `--container-image` 的 Slurm SPANK plugin）的架構設計：
1. **Login node（`S_CTX_LOCAL`）**：只負責解析和傳遞參數，不做任何檔案 I/O
2. **Worker node（`S_CTX_REMOTE`）**：`slurmstepd` 進程實際讀取 `.sqsh` 檔案並呼叫 `enroot create`
原始碼中路徑解析（`pyxis_slurmstepd.c`）：
```c
if (strspn(context.args->image, "./") > 0) {
context.container.squashfs_path = strdup(context.args->image);
}
```
此段程式碼只在 worker node 上執行。Pyxis **不會**自動將檔案從 login node 傳輸到 worker node。
---
### Q: 我的指令失敗了，如何排查？
**A:** 確認檔案是否存在於目標 worker node：
```bash
# 檢查 worker node 上是否有該檔案
srun -p a30-set -w c8m64gt1-0 ls -l /mnt/data/ubuntu+24.04.sqsh
```
如果回傳 `No such file or directory`，代表 `.sqsh` 檔只在 login node 上，尚未存在於 worker node。
---
### Q: 如何解決檔案不在 worker node 上的問題？
| 方法 | 指令範例 | 適用情境 |
|------|----------|----------|
| 放到共享儲存 | `cp /mnt/data/ubuntu+24.04.sqsh /shared/containers/` | 叢集有 NFS/Lustre 共享目錄 |
| 手動複製到 worker | `scp /mnt/data/ubuntu+24.04.sqsh c8m64gt1-0:/mnt/data/` | 單次測試、快速驗證 |
| 改用 Docker URI | `--container-image=docker://ubuntu:24.04` | 不想管路徑，讓 Pyxis 自動 pull 並快取 |
---
### Q: 如果我的 `/mnt/data` 是各節點共享的（NFS mount），還需要擔心嗎？
**A: 不需要。** 如果 `/mnt/data` 是共享檔案系統，login node 和 worker node 看到的是同一份檔案，指令可以直接運作。可用以下方式確認：
```bash
# 確認 /mnt/data 是否為共享掛載
srun -w c8m64gt1-0 df /mnt/data
```
若顯示的裝置與 login node 上 `df /mnt/data` 相同，表示是共享的。
---
### Q: 完整的測試指令範例？
```bash
# 在 worker node 上用 ubuntu+24.04.sqsh 容器執行 ls /
time srun -p a30-set -w c8m64gt1-0 --container-image=/mnt/data/ubuntu+24.04.sqsh ls /
```
---
---
## sacct
> - 用來顯示 job 的執行狀況
> - 只能看到自己帳號內的 job
```
$ sacct
JobID JobName Partition Account AllocCPUS State ExitCode
------------ ---------- ---------- ---------- ---------- ---------- --------
12 nvidia-smi tn 1 RUNNING 0:0
12.extern extern 1 RUNNING 0:0
12.0 nvidia-smi 1 RUNNING 0:0
13 nvidia-smi tn 0 CANCELLED+ 0:0
14 nvidia-smi tn 1 COMPLETED 0:0
14.extern extern 1 COMPLETED 0:0
14.0 nvidia-smi 1 COMPLETED 0:0
```
**進一步查詢 job 12**
```
$ scontrol show job 12
JobId=12 JobName=nvidia-smi
UserId=tj_tsai(10001) GroupId=gid10000(10000) MCS_label=N/A
Priority=1 Nice=0 Account=(null) QOS=normal
JobState=RUNNING Reason=None Dependency=(null)
Requeue=1 Restarts=0 BatchFlag=0 Reboot=0 ExitCode=0:0
RunTime=01:03:07 TimeLimit=UNLIMITED TimeMin=N/A
SubmitTime=2025-10-16T08:41:08 EligibleTime=2025-10-16T08:41:08
AccrueTime=Unknown
StartTime=2025-10-16T08:41:08 EndTime=Unknown Deadline=N/A
SuspendTime=None SecsPreSuspend=0 LastSchedEval=2025-10-16T08:41:08 Scheduler=Main
Partition=tn AllocNode:Sid=slurm-login-slinky-765f696cc5-5vkfs:1362
ReqNodeList=esc8000a-0 ExcNodeList=(null)
NodeList=esc8000a-0
BatchHost=esc8000a-0
StepMgrEnabled=Yes
NumNodes=1 NumCPUs=1 NumTasks=1 CPUs/Task=1 ReqB:S:C:T=0:0:*:*
ReqTRES=cpu=1,mem=4G,node=1,billing=1,gres/gpu=1
AllocTRES=cpu=1,mem=4G,node=1,billing=1,gres/gpu=1
Socks/Node=* NtasksPerN:B:S:C=0:0:*:* CoreSpec=*
MinCPUsNode=1 MinMemoryCPU=4G MinTmpDiskNode=0
Features=(null) DelayBoot=00:00:00
OverSubscribe=OK Contiguous=0 Licenses=(null) LicensesAlloc=(null) Network=(null)
Command=nvidia-smi
WorkDir=/mnt/data/sqsh
TresPerNode=gres/gpu:1
```
- 可以查其他不屬於自己的 job
---
---
## 討論
### 如何查看 sbatch 的執行結果？
- ### Question
```
$ sbatch -A tj-account -p debug -N1 -n1 --wrap='hostname && whoami'
Submitted batch job 959
```
要如何查看執行結果？
- ### gpt-5 (2025/08/28)
最直接的方法有三種：看 **狀態**、找 **輸出檔**、查 **帳務紀錄**。
### 1) 先看工作狀態
```bash
# 只看這個工作
squeue -j 959
# 看詳細資訊（含原因、輸出路徑等）
scontrol show job 959 | egrep 'JobState|Reason|NodeList|StdOut|WorkDir'
```
- **執行範例**：
```
$ scontrol show job 959
JobId=959 JobName=wrap
UserId=tmp1(20011) GroupId=tj-account(1002) MCS_label=N/A
Priority=1 Nice=0 Account=tj-account QOS=normal
JobState=FAILED Reason=RaisedSignal:53(Real-time_signal_19) Dependency=(null)
Requeue=1 Restarts=0 BatchFlag=1 Reboot=0 ExitCode=0:53
RunTime=00:00:01 TimeLimit=UNLIMITED TimeMin=N/A
SubmitTime=2025-08-28T07:07:53 EligibleTime=2025-08-28T07:07:53
AccrueTime=2025-08-28T07:07:53
StartTime=2025-08-28T07:07:53 EndTime=2025-08-28T07:07:54 Deadline=N/A
SuspendTime=None SecsPreSuspend=0 LastSchedEval=2025-08-28T07:07:53 Scheduler=Main
Partition=tn AllocNode:Sid=slurm-login-6fb5d948d6-5mcvp:193068
ReqNodeList=(null) ExcNodeList=(null)
NodeList=esc8000b-0
BatchHost=esc8000b-0
StepMgrEnabled=Yes
NumNodes=1 NumCPUs=2 NumTasks=1 CPUs/Task=1 ReqB:S:C:T=0:0:*:*
ReqTRES=cpu=1,mem=240G,node=1,billing=1
AllocTRES=cpu=2,mem=240G,node=1,billing=2
Socks/Node=* NtasksPerN:B:S:C=0:0:*:* CoreSpec=*
MinCPUsNode=1 MinMemoryNode=0 MinTmpDiskNode=0
Features=(null) DelayBoot=00:00:00
OverSubscribe=OK Contiguous=0 Licenses=(null) LicensesAlloc=(null) Network=(null)
Command=(null)
WorkDir=/home/tmp1
StdErr=/home/tmp1/slurm-959.out
StdIn=/dev/null
StdOut=/home/tmp1/slurm-959.out
```
### 2) 讀取輸出檔（預設在提交指令的目錄）
`sbatch` 預設把 stdout/stderr 寫到 `slurm-
### 沒有看到 sbatch 的執行結果？
> :warning: **關鍵點**：
> - compute node 的 user id ，要跟 login node 的 user id 一致
> - gid 不一致好像不影響
- ### Question
```
$ sbatch -A tj-account -p debug -N1 -n1 --wrap='hostname && whoami'
Submitted batch job 961
```
執行了 sbatch, 但在 login 節點或是 compute 節點，都沒看到 961.out
```
tmp1@slurm-login-6fb5d948d6-5mcvp:~$ scontrol show job 961
JobId=961 JobName=wrap
UserId=tmp1(20011) GroupId=tj-account(1002) MCS_label=N/A
Priority=1 Nice=0 Account=tj-account QOS=normal
JobState=FAILED Reason=RaisedSignal:53(Real-time_signal_19) Dependency=(null)
Requeue=1 Restarts=0 BatchFlag=1 Reboot=0 ExitCode=0:53
RunTime=00:00:01 TimeLimit=UNLIMITED TimeMin=N/A
SubmitTime=2025-08-28T07:13:57 EligibleTime=2025-08-28T07:13:57
AccrueTime=2025-08-28T07:13:57
StartTime=2025-08-28T07:13:57 EndTime=2025-08-28T07:13:58 Deadline=N/A
SuspendTime=None SecsPreSuspend=0 LastSchedEval=2025-08-28T07:13:57 Scheduler=Main
Partition=debug AllocNode:Sid=slurm-login-6fb5d948d6-5mcvp:193068
ReqNodeList=(null) ExcNodeList=(null)
NodeList=e900-0
BatchHost=e900-0
StepMgrEnabled=Yes
NumNodes=1 NumCPUs=2 NumTasks=1 CPUs/Task=1 ReqB:S:C:T=0:0:*:*
ReqTRES=cpu=1,mem=240G,node=1,billing=1
AllocTRES=cpu=2,mem=240G,node=1,billing=2
Socks/Node=* NtasksPerN:B:S:C=0:0:*:* CoreSpec=*
MinCPUsNode=1 MinMemoryNode=0 MinTmpDiskNode=0
Features=(null) DelayBoot=00:00:00
OverSubscribe=OK Contiguous=0 Licenses=(null) LicensesAlloc=(null) Network=(null)
Command=(null)
WorkDir=/home/tmp1
StdErr=/home/tmp1/slurm-961.out
StdIn=/dev/null
StdOut=/home/tmp1/slurm-961.out
```
```
root@slurm-login-6fb5d948d6-5mcvp:/tmp# ll /home
total 36
drwxr-xr-x 1 root root 4096 Aug 28 06:42 ./
drwxr-xr-x 1 root root 4096 Aug 26 03:44 ../
drwxr-x--- 2 tmp1 tj-account 4096 Aug 28 07:09 tmp1/
root@slurm-login-6fb5d948d6-5mcvp:/tmp# ll /home/tmp1
total 24
drwxr-x--- 2 tmp1 tj-account 4096 Aug 28 07:09 ./
drwxr-xr-x 1 root root 4096 Aug 28 06:42 ../
-rw------- 1 tmp1 tj-account 260 Aug 28 07:09 .bash_history
-rw-r--r-- 1 tmp1 tj-account 220 Mar 31 2024 .bash_logout
-rw-r--r-- 1 tmp1 tj-account 3771 Mar 31 2024 .bashrc
-rw-r--r-- 1 tmp1 tj-account 807 Mar 31 2024 .profile
```
```
$ kubectl -n slurm exec -it pod/slurm-compute-e900-0 -- bash
root@e900-0:/tmp# ll /home/
total 8
drwxr-xr-x 1 root root 4096 Aug 26 09:26 ./
drwxr-xr-x 1 root root 4096 Aug 5 14:13 ../
```
- ### gpt-5 (2025/08/28)
你這個症狀其實已經「自白」了：
* `scontrol show job 961` 顯示
* `StdOut=/home/tmp1/slurm-961.out`
* `WorkDir=/home/tmp1`
* `BatchHost=e900-0`
* 但 **compute 節點 pod `slurm-compute-e900-0` 裡根本沒有 `/home/tmp1`（甚至 `/home/` 是空的）**
* 結果：Slurm 在 **e900-0** 要建立/寫入 `/home/tmp1/slurm-961.out` 時 I/O 失敗，工作被即時訊號殺掉 → `JobState=FAILED Reason=RaisedSignal:53(Real-time_signal_19)`；這類代碼常見成因就是 **stdout/stderr 路徑不存在或無法寫入**。([Stack Overflow][1], [bugs.schedmd.com][2], [Reddit][3])
換句話說：**login pod 有 `/home/tmp1`，compute pod 沒有**；/home 沒有做共享掛載。
---
### 立刻確認 / 取得輸出（快速救急）
1. 直接用 `srun` 偵錯（會把輸出寫回終端，不依賴檔案）：
```bash
srun -A tj-account -p debug -N1 -n1 bash -lc 'hostname && whoami'
```
- 這能快速看出是否是路徑/權限問題（`sbatch` 常把這類錯誤吞掉）。([Stack Overflow][1])
- `bash -lc 'hostname && whoami'`
- `-l`：代表 **login shell**，會讓 `bash` 模擬使用者登入時的環境（讀取 `/etc/profile`、`~/.bash_profile` 等設定檔）。
- `-c`：代表 **command**，後面接要執行的字串命令。
- **指令意思**：
啟動一個登入型的 bash，再執行 `'hostname && whoami'` 這串命令。
- ### :warning: Error: couldn't chdir to `/home/tmp1': Permission denied: going to /tmp instead
```
$ srun -A tj-account -p debug -N1 -n1 bash -lc 'hostname && whoami'
[2025-08-28T07:30:02.233] error: couldn't chdir to `/home/tmp1': Permission denied: going to /tmp instead
[2025-08-28T07:30:02.235] error: couldn't chdir to `/home/tmp1': Permission denied: going to /tmp instead
/usr/bin/bash: /home/tmp1/.bash_profile: Permission denied
e900-0
tmp1
```
- **原因**：login pod 的 user id，跟 compute pod 的 user id 不一致
- **解法**：建立 user OS 帳號時，需指定相同 uid (`-u 20011`)
```
sudo useradd -m -u 20011 -s /bin/bash tmp1
```
2. 用存在的目錄當輸出與工作目錄（在 **compute** 一定存在的如 `/tmp`）再試一次：
```bash
sbatch -A tj-account -p debug \
--chdir=/tmp \
-o /tmp/slurm-%j.out -e /tmp/slurm-%j.err \
--wrap='hostname && whoami'
```
- 其中 `%j`=JobID 、 `%x`=JobName (`%x='wrap'`)。
跑完到 **compute 節點 pod** 取檔：
```bash
kubectl -n slurm exec -it pod/slurm-compute-e900-0 \
-- bash -lc 'ls -l /tmp/slurm-*.out; tail -n +1 /tmp/slurm-*.out'
```
3. 查帳務記錄（看退出碼/狀態）：
```bash
sacct -j 961 --format=JobID,State,ExitCode,NodeList,StdOut,WorkDir
```
- **執行範例**：
```
$ sacct -j 961 --format=JobID,State,ExitCode,NodeList,StdOut,WorkDir
JobID State ExitCode NodeList StdOut WorkDir
------------ ---------- -------- --------------- -------------------- --------------------
961 FAILED 0:53 e900-0 /home/tmp1/slurm-%j+ /home/tmp1
961.batch CANCELLED 0:53 e900-0
961.extern COMPLETED 0:0 e900-0
```
> 遇到 Linux 訊號終止（含 real-time signals），Slurm 會把訊號號碼記錄在 ExitCode 後半部。([Slurm][4])
---
### 正解：把 **/home** 做成共享掛載（login 與 compute 都要同一份）
目前你在 login pod 看得到 `/home/tmp1`，但在 compute pod 看不到 → **/home 未共享**。要修好：
1. 準備一個可共享的儲存（NFS 或 PVC）並放使用者家目錄：
* 例：NFS 伺服器上 export `/nfs/home`，或 K8s 建 `home-pvc`（容量依需求）。
2. **同時**把這個卷掛到
* login pod：`mountPath: /home`
* 所有 slurmd 的 compute pods：`mountPath: /home`
3. 確保目錄與擁有者一致（UID/GID 在 login/compute 一致）。你的 `tmp1` 是 `uid=20011`、`gid=tj-account(1002)`，所以在共享卷上要：
```bash
# 在共享卷上（一次就好）
mkdir -p /home/tmp1
chown 20011:1002 /home/tmp1
chmod 750 /home/tmp1
```
> 具體怎麼在 Helm values 設置要看你用的 chart/版本，但原則就是：**同一個 PVC/NFS 同時掛到 login 與 slurmd pods 的 `/home`**。若暫時無法調整，至少在每個 compute pod 先建立目錄（僅測試用，pod 重建就沒了）：
```bash
kubectl -n slurm exec -it pod/slurm-compute-e900-0 \
-- bash -lc 'mkdir -p /home/tmp1 && chown 20011:1002 /home/tmp1'
```
---
## 之後的最佳實務
* 明確指定輸出位置到**共享**路徑（好找又持久）：
```bash
sbatch -A tj-account -p debug \
-o /home/tmp1/slurm/%x-%j.out \
-e /home/tmp1/slurm/%x-%j.err \
--wrap='hostname && whoami'
```
- 其中 `%j`=JobID 、 `%x`=JobName (`%x='wrap'`)。
（先 `mkdir -p /home/tmp1/slurm`）
* 若看到 `RaisedSignal:53` 或 `.out` 檔不見蹤影，**第一時間檢查輸出路徑是否存在/可寫、配額是否滿**。([bugs.schedmd.com][2], [HPC Community][5])
---
### 為什麼你剛剛兩邊都找不到 `slurm-961.out`？
因為 Slurm 試圖在 **e900-0** 的 `/home/tmp1/` 建檔，但 **那個路徑不存在**，工作一開始就因 I/O 問題被結束；自然就沒有任何 `.out` 可以在 login 或 compute 的 `/home` 找到。這正是社群常見案例：**stdout 目錄不存在 → 失敗且常看不到明確錯誤**。([Stack Overflow][1], [bugs.schedmd.com][2])
需要的話，我可以幫你把目前的 Helm values 片段貼過來，給你對應的 `extraVolumes/extraVolumeMounts`（或 chart 自帶的 home 共享設定）範例，直接套用到 login 與 slurmd。
[1]: https://stackoverflow.com/questions/77642713/all-slurm-jobs-fail-silently-with-exit-code-053?utm_source=chatgpt.com "All slurm jobs fail silently with exit code 0:53"
[2]: https://bugs.schedmd.com/show_bug.cgi?id=8895&utm_source=chatgpt.com "Slurm job output to non-existent directory result into silent ..."
[3]: https://www.reddit.com/r/HPC/comments/1fklwa6/need_help_slurm_error_code_053/?utm_source=chatgpt.com "Need Help SLURM Error Code 0:53 : r/HPC"
[4]: https://slurm.schedmd.com/job_exit_code.html?utm_source=chatgpt.com "Job Exit Codes - Slurm Workload Manager - SchedMD"
[5]: https://hpc-community.unige.ch/t/cpu-gpu-job-failing/3432?utm_source=chatgpt.com "CPU/GPU job failing"
{%hackmd vaaMgNRPS4KGJDSFG0ZE0w %}