{"id":"IL-0426","org":"Hugging Face","date":"2023-03-04","docs":[],"title":{"en":"A 64-GPU training run on Jean Zay hung after 3.5 hours when rank 0 stuck in uninterruptible sleep on a frozen filesystem","ko":"64 GPU 학습이 3.5시간 뒤 멈췄고 30분 c10d 타임아웃이 지나도 끝나지 않았다"},"domain":["ai-infra"],"impact":{"scope":"A 64-GPU training run on 8 Jean Zay nodes hung indefinitely; the stuck rank 0 process on jean-zay-iam06 could only be cleared by rebooting the node","users":"unknown","region":"unknown"},"review":{"written_by":"session","reviewed_at":null,"reviewed_by":null},"lessons":null,"related":[],"sources":[{"url":"https://github.com/huggingface/m4-logs/blob/master/tr_141-hanging/tr_141_cm409xPMD01_scale_leap_of_faith_v5_num_workers_0-try3/README.md","kind":"github","archived":null}],"summary":{"en":"Hugging Face was running the m4 experiment tr_141 on 64 GPUs across 8 nodes of the Jean Zay HPC cluster (GPU 0 on the stuck node was an NVIDIA A100-SXM4-80GB), with PyTorch 1.12, accelerate and DeepSpeed, CUDA_LAUNCH_BLOCKING=1 and num_workers=2. After about 3.5 hours of training the job froze. Because c10d never aborted the job, the engineer could study it while it hung: the log showed gradient clipping as the last step, py-spy put the other ranks in a torch.distributed barrier, and the one process that did not answer was rank 0 on node jean-zay-iam06 (GPU 0, process 280058). strace and py-spy could not attach to it, ps showed it in uninterruptible sleep, and nvidia-smi and dmesg showed nothing wrong with the GPU.\n\nThe next day the Jean Zay system administrators announced that the filesystem had suffered a meltdown. That explained the hang: rank 0 had made a system call to write to its log, the call never returned because the filesystem was frozen, the process went into uninterruptible sleep, and the other ranks waited for it in the barrier. The c10d timeout did not fire, so the whole job stayed frozen instead of failing, and the stuck process could only be cleared by rebooting the node.","ko":"실험 3.1 은 8개 노드의 GPU 64개로 pt-1.12, `CUDA_LAUNCH_BLOCKING=1`, num_workers=2 설정에서 돌았다. 학습은 3.5시간쯤 지나 멈췄다. node0 의 rank 0 프로세스가 uninterruptible sleep 상태에 빠져 응답하지 않았고, 나머지 프로세스는 barrier 에서 그 프로세스를 기다렸다. c10d 는 30분 타임아웃이 지나도 작업을 중단하지 않아서 작업은 끝없이 멈춰 있었다.\n\n작성자는 py-spy 로 모든 노드를 덤프해 jean-zay-iam06 을 찾았고, nvidia-smi 로 GPU 0 의 PID 280058 을 찾았다. 이 프로세스에는 strace 와 py-spy 를 붙일 수 없었고 ps 상태는 `Dl` 이었다. 작성자는 노드를 재부팅하는 것 말고는 이 프로세스를 어떻게 할 방법이 없다고 판단했다. GPU 의 온도, ECC 오류, 커널 로그에는 이상이 없었다.\n\n다음 날 시스템 관리자가 파일 시스템에 큰 장애가 있었다고 알렸다. 파일 시스템이 멈춰 응답하지 않는 동안 rank 0 프로세스가 로그를 쓰려 했고, 그 시스템 콜이 돌아오지 않아 프로세스가 uninterruptible sleep 상태에 빠졌다. 이 프로세스 하나 때문에 학습 전체가 멈췄다."},"trigger":{"en":"The filesystem of the Jean Zay HPC system froze and stopped responding while rank 0 on the first node was writing to its log.","ko":"HPC 클러스터의 파일 시스템이 멈춰 응답하지 않게 됐다. 그때 node0 의 rank 0 프로세스가 로그를 쓰려고 부른 시스템 콜이 돌아오지 않았다."},"severity":"unknown","symptoms":["training-job-failed","nccl-timeout"],"timeline":{"detected_after":null,"resolved_after":null},"date_kind":"incident","detection":{"en":"The engineer, who happened to be around, noticed that the main training log had stopped being written.","ko":"작성자가 마침 자리에 있다가 메인 로그가 더 써지지 않는 것을 보고 알아챘다. 파일 시스템이 원인이라는 것은 다음 날 시스템 관리자의 공지로 알았다."},"components":["shared-filesystem","pytorch"],"root_cause":"dependency-failure","remediation":[],"action_items":[],"contributing":["limited-debug-access"],"recurrence_of":null,"symptoms_text":{"en":"A 64-GPU training run (experiment tr_141, 8 nodes of the Jean Zay cluster) stopped making progress after about 3.5 hours: the main log stopped being written and the job hung without exiting. The c10d timeout of 30 minutes did not abort it, and the job stayed frozen indefinitely. The same hang had already happened on a different set of nodes, which first pointed to a software problem.\n\nThe last lines of the main log were per-process messages such as \"Before sync_gradients in _do_batch\" and \"After clip in _do_batch\", so gradient clipping was the last step that ran. A py-spy dump of every process showed the ranks waiting in \"barrier (torch/distributed/distributed_c10d.py:2784)\" called from accelerate's \"wait_for_everyone\". Node jean-zay-iam06 returned one report fewer than the other nodes, and running py-spy on it directly failed with \"Error: Failed to suspend process\" and \"Reason: EPERM: Operation not permitted\".\n\nOn jean-zay-iam06, nvidia-smi showed seven GPUs at 100% utilization and GPU 0 at 0%, held by process 280058. Attaching strace to that process failed with \"strace: attach: ptrace(PTRACE_SEIZE, 280058): Operation not permitted\", and ps showed it in state \"Dl\" (uninterruptible sleep, usually IO) while the other seven training processes were \"Rl\". A process in this state could only be cleared by rebooting the node.\n\nThe GPU itself looked healthy. nvidia-smi -q for GPU 0 showed 28 C, ECC mode enabled with zero correctable and uncorrectable errors, and no remapped rows; its clocks were at 1155 MHz against 1410 MHz on the other seven GPUs, which the engineer thought might be normal for a GPU at 0% utilization that had slowed itself down. dmesg had nothing from NVRM or nvidia around the time of the hang, only failed kernel stacks from the attempts to attach to the sleeping process.","ko":"8개 노드의 GPU 64개로 돌던 학습이 3.5시간쯤 지나 멈췄다. 메인 로그가 더는 써지지 않았고, 30분짜리 c10d 타임아웃이 지나도 작업이 중단되지 않고 계속 멈춰 있었다.\n\n메인 로그의 마지막 줄들은 `PID 280058:  After clip in _do_batch` 같은 줄이었다. 마지막으로 돈 단계는 그래디언트 클리핑이었다.\n\npy-spy 로 8개 노드의 프로세스를 덤프하자 응답한 프로세스는 모두 `barrier (torch/distributed/distributed_c10d.py:2784)` 에서 기다리고 있었다. 덤프 뒤에 `sleep 3` 을 넣어 다시 돌리자 다른 노드는 모두 프로세스 8개가 barrier 에 있었고 jean-zay-iam06 만 모자랐다. 그 노드에서는 프로세스 하나의 덤프가 `Error: Failed to suspend process` 와 `Reason: EPERM: Operation not permitted` 로 실패했다.\n\njean-zay-iam06 의 nvidia-smi 에서 GPU 7개는 사용률 100% 였고 GPU 0 만 0% 였다. GPU 0 의 프로세스는 PID 280058 이었다. 정상 프로세스에 strace 를 붙이면 nvidiactl 장치를 ioctl 로 폴링하는 것이 보였지만, 280058 에 붙이면 `strace: attach: ptrace(PTRACE_SEIZE, 280058): Operation not permitted` 가 났다. ps 의 STAT 칸에서 280058 만 `Dl` 이었고 나머지는 `Rl` 이었다. STAT 의 D 는 대개 IO 를 기다리는 uninterruptible sleep 상태를 뜻한다.\n\n같은 멈춤이 다른 노드에서도 되풀이됐기 때문에, 작성자는 처음에 소프트웨어 문제로 보고 멈춤을 일으키는 계기를 찾았다. GPU 0 자체는 정상으로 보였다. 온도는 28 C 였고 ECC 오류는 0 이었다. 클럭은 1155 MHz 로 다른 GPU 의 1410 MHz 보다 낮았지만, 사용률이 0% 라서 GPU 가 스스로 클럭을 낮춘 것일 수 있다고 봤다. `dmesg -H` 에는 그 시각 전후로 NVRM 이나 nvidia 메시지가 없었고, 멈춘 프로세스에 붙으려다 실패한 커널 스택만 있었다."},"updated_at":"2026-11-14T12:34:07.645733Z","url":"https://benchlet.com/incidentlib/app/cases/IL-0426","org_slug":"hugging-face"}