[🧯 systemctl timeout 장애 분석] systemd/D-Bus, Lustre, InfiniBand 문제 쉽게 이해하기 !!

 

 

 

1. 장애 상황 요약 🚨

운영 중인 GPU 서버에서 아래와 같은 증상이 발생했습니다.

systemctl status slurmd

실행 결과:

Failed to get properties: Failed to activate service 'org.freedesktop.systemd1': timed out
(service_start_timeout=25000ms)

처음 보면 slurmd 서비스가 죽은 것처럼 보일 수 있습니다.
하지만 실제로는 slurmd 자체 문제라기보다 systemctl이 systemd와 통신하지 못해 timeout이 발생한 상황으로 보는 것이 더 정확합니다.

또한 같은 시간대에 Lustre 파일시스템 관련 로그도 함께 확인되었습니다.

LNet: peer NIs in recovery
Lustre: Request sent has timed out
Connection to OST was lost
Connection restored

즉, 이번 장애는 단순히 서비스 하나가 죽은 문제가 아니라,

Lustre over InfiniBand 통신 지연 또는 끊김이 발생했고, 그 영향으로 systemd/D-Bus 응답까지 지연된 장애

로 판단할 수 있습니다.

---

2. 먼저 결론부터 ✅

이번 유형의 장애는 아래처럼 정리할 수 있습니다.

GPU 문제 아님
Docker 직접 문제 가능성 낮음
메모리 부족 가능성 낮음
systemctl ↔ systemd/D-Bus 통신 timeout 발생
Lustre/LNet/InfiniBand 경로 불안정 가능성 높음
리부팅 후 해결됐다면 노드 내부 상태 꼬임 가능성 높음

특히 nvidia-smi가 정상 출력되고 GPU 프로세스도 없었다면, GPU 장애보다는 OS 서비스 관리 계층 또는 스토리지 네트워크 계층 문제를 먼저 의심해야 합니다.

---

3. systemd란? 🧠

systemd 쉽게 설명하기

systemd는 Linux 서버에서 서비스를 시작하고, 중지하고, 상태를 관리하는 관리자입니다.

예를 들어 아래 명령어들은 모두 systemd를 통해 동작합니다.

systemctl status ssh
systemctl restart docker
systemctl status slurmd
systemctl stop nginx

쉽게 말하면 systemd는 서버 안에서 이런 역할을 합니다.

역할설명

서비스 시작	ssh, docker, slurmd 같은 서비스 실행
서비스 중지	필요 없는 서비스 종료
서비스 재시작	장애 시 서비스 재기동
상태 확인	서비스가 정상인지 확인
부팅 관리	서버 켜질 때 어떤 서비스를 띄울지 관리

즉, systemd는 Linux 서버의 서비스 관리자입니다.

---

4. D-Bus란? 🚌

D-Bus 쉽게 설명하기

D-Bus는 Linux 내부에서 프로그램끼리 대화할 때 사용하는 통신 버스입니다.

예를 들어 사용자가 아래 명령어를 실행한다고 가정해보겠습니다.

systemctl status slurmd

이때 흐름은 단순히 slurmd 프로세스를 직접 보는 것이 아닙니다.

사용자
  ↓
systemctl 명령어
  ↓
D-Bus
  ↓
systemd
  ↓
slurmd 상태 조회

즉, systemctl은 systemd에게 직접 말을 거는 것이 아니라, 중간에 D-Bus라는 통신 경로를 통해 요청을 보냅니다.

그래서 D-Bus 또는 systemd 응답이 느려지면 아래와 같은 에러가 발생할 수 있습니다.

Failed to activate service 'org.freedesktop.systemd1': timed out

---

5. org.freedesktop.systemd1 이게 뭐야? 🔍

에러에 나온 이 문구가 중요합니다.

org.freedesktop.systemd1

이것은 D-Bus에서 systemd를 가리키는 이름입니다.

쉽게 표현하면:

org.freedesktop.systemd1 = D-Bus에서 systemd를 부르는 이름

따라서 아래 에러는:

Failed to activate service 'org.freedesktop.systemd1': timed out

다음과 같은 의미입니다.

systemctl이 D-Bus를 통해 systemd에게 물어봤는데, systemd 쪽 응답이 25초 안에 오지 않았다.

즉, 서비스 상태 조회 자체가 실패한 것이지, 반드시 slurmd가 죽었다는 뜻은 아닙니다.

---

6. 장애에서 중요한 로그들 📌

6-1. systemctl timeout

Failed to get properties:
Failed to activate service 'org.freedesktop.systemd1': timed out

의미:

systemctl이 systemd/D-Bus와 정상 통신하지 못함

---

6-2. systemd-journald WATCHDOG 실패

systemd-journald:
Failed to send WATCHDOG=1 notification message:
Transport endpoint is not connected

의미:

systemd-journald가 systemd로 상태 알림을 보내려 했지만 실패

이 로그는 systemd, journald, notify socket 쪽 통신이 순간적으로 불안정했을 가능성을 보여줍니다.

---

6-3. Lustre timeout

Lustre: Request sent has timed out

의미:

Lustre 클라이언트가 스토리지 서버에 요청을 보냈지만 응답이 지연됨

---

6-4. OST connection lost/restored

Connection to OST was lost
Connection restored

의미:

Lustre OST와 연결이 잠시 끊겼다가 다시 복구됨

여기서 중요한 점은 restored입니다.

완전히 끊긴 장애라기보다는, 끊김과 복구가 반복된 간헐성 장애로 볼 수 있습니다.

---

6-5. LNet peer NIs in recovery

LNet: peer NIs in recovery

의미:

Lustre 네트워크 계층에서 특정 peer와의 통신이 recovery 상태에 들어감

Lustre를 InfiniBand로 사용하는 환경에서는 보통 o2ib 네트워크를 사용합니다.

예시:

192.168.100.11@o2ib
192.168.100.12@o2ib

@o2ib가 보이면 Lustre가 InfiniBand/RDMA 경로로 통신하고 있다는 뜻입니다.

---

7. Docker나 메모리 문제였을까? 🐳

이번 로그만 보면 Docker나 메모리 과다 사용이 직접 원인일 가능성은 낮습니다.

Docker 문제라면 보통 이런 로그가 나옵니다.

docker
containerd
buildkit
runc
container failed

메모리 부족이면 보통 이런 로그가 나옵니다.

Out of memory
oom-killer
Killed process
Memory cgroup out of memory

하지만 이번 장애 로그의 핵심은 아래였습니다.

Lustre timeout
LNet recovery
OST connection lost/restored
systemd-journald watchdog failure
systemctl D-Bus timeout

따라서 직접 원인은 Docker/메모리보다는 Lustre/InfiniBand 통신 불안정 쪽에 더 가깝습니다.

단, Docker 컨테이너가 Lustre 경로에 대량 I/O를 발생시켰다면 간접 영향은 가능합니다.

예를 들면:

컨테이너 대량 파일 읽기/쓰기
  ↓
Lustre I/O 증가
  ↓
OST 응답 지연
  ↓
Lustre timeout
  ↓
systemd 응답 지연

이런 흐름은 가능하므로 Docker I/O 여부는 별도 확인이 필요합니다.

---

8. 리부팅 후 해결됐는데 Lustre 문제가 맞을까? 🔄

많이 헷갈리는 부분입니다.

Lustre 문제면 리부팅해도 계속 문제가 있어야 하는 것 아닌가?

꼭 그렇지는 않습니다.

Lustre 문제는 크게 두 가지로 나눌 수 있습니다.

8-1. 스토리지 서버 또는 IB 스위치 전체 문제

이 경우에는 특정 노드만 리부팅해도 문제가 계속될 가능성이 큽니다.

스토리지 서버 장애
IB 스위치 장애
공통 네트워크 경로 장애

이런 경우는 여러 노드에서 동시에 문제가 발생합니다.

---

8-2. 특정 노드의 Lustre client/LNet/IB 상태 꼬임

이 경우는 노드 리부팅으로 해결될 수 있습니다.

특정 노드의 Lustre client 세션 꼬임
LNet recovery 상태 지속
IB/RDMA 연결 상태 이상
mlx5 드라이버 상태 이상
mount 상태 hang

리부팅하면 아래 항목들이 초기화됩니다.

Lustre client 세션
LNet 상태
IB/RDMA 연결
mlx5 드라이버 상태
systemd/D-Bus 상태
mount 상태

따라서 리부팅 후 해결됐다면,

스토리지 전체 장애보다는 해당 노드의 Lustre client/LNet/IB 세션 상태가 일시적으로 꼬였던 가능성

이 더 높습니다.

---

9. 장애 발생 시 점검 명령어 정리 🛠️

9-1. systemd 전체 상태 확인

systemctl is-system-running

출력 예시:

출력	의미
running	전체적으로 정상
degraded	일부 서비스 실패
starting	서비스 시작 중
maintenance	복구 모드
offline	systemd 통신 불가 가능성
unknown	상태 확인 불가

timeout을 걸어서 확인하려면:

timeout 5 systemctl is-system-running
echo $?

124가 나오면 timeout 명령에 의해 강제 종료된 것입니다.

---

9-2. 실패한 서비스 확인

systemctl --failed

또는:

systemctl list-units --state=failed

---

9-3. systemctl 자체가 먹통인지 확인

timeout 5 systemctl status ssh
timeout 5 systemctl --failed
timeout 5 systemctl is-system-running

모두 timeout이면 특정 서비스 문제가 아니라 systemd/D-Bus 통신 문제일 수 있습니다.

---

9-4. D-Bus 상태 확인

ps -ef | grep dbus | grep -v grep

timeout 5 busctl list | head

busctl도 timeout이면 D-Bus 또는 systemd 통신 경로 문제 가능성이 큽니다.

---

9-5. PID 1 systemd 상태 확인

ps -p 1 -o pid,comm,state,etime

정상 예시:

PID COMMAND STATE ELAPSED
1   systemd S     10-03:22:11

---

9-6. journald 상태 확인

ps -ef | grep systemd-journald | grep -v grep

journalctl -u systemd-journald --since "30 min ago"

systemctl이 timeout이면 journalctl도 느릴 수 있으므로, 먼저 프로세스 확인부터 하는 것이 좋습니다.

---

9-7. D state 프로세스 확인

I/O hang이 발생하면 프로세스가 D 상태에 빠질 수 있습니다.

ps -eo state,pid,ppid,comm,wchan:30 | awk '$1 ~ /D/ {print}'

D 상태가 많으면 디스크, Lustre, NFS, IB/RDMA 지연을 의심해야 합니다.

---

9-8. 커널 로그 확인

dmesg -T | egrep -i "blocked|hung|task|lustre|lnet|o2ib|ptlrpc|mlx5|ib|infiniband|transport endpoint"

또는 특정 시간대로 확인:

journalctl -k --since "2026-06-14 00:10" --until "2026-06-14 00:30" \
| egrep -i "lustre|lnet|o2ib|ptlrpc|recovery|mlx5|infiniband|transport endpoint"

---

9-9. Lustre 상태 확인

lctl get_param health_check

lctl list_nids

lnetctl net show

lnetctl peer show

마운트 확인:

mount | grep lustre

주의할 점:

df -h

df -h는 파일시스템이 hang 상태면 명령어 자체가 멈출 수 있습니다.
그래서 운영 중에는 timeout을 거는 것이 좋습니다.

timeout 5 df -h

---

9-10. InfiniBand 상태 확인

ibstat

ibstatus

포트 상태 확인:

cat /sys/class/infiniband/*/ports/*/state
cat /sys/class/infiniband/*/ports/*/phys_state

mlx5 관련 커널 로그:

dmesg -T | egrep -i "mlx5|infiniband|ib|link|port|error|down|polling"

포트 에러 카운터:

perfquery

---

9-11. Slurm daemon 직접 확인

systemctl status slurmd가 timeout 난다고 해서 slurmd가 무조건 죽은 것은 아닙니다.

먼저 프로세스를 직접 확인합니다.

ps -ef | grep slurmd | grep -v grep

포트 확인:

ss -lntp | grep slurmd

로그 확인:

journalctl -u slurmd --since "1 hour ago"

파일 로그가 있으면:

tail -100 /var/log/slurmd.log

---

9-12. GPU 상태 확인

nvidia-smi

상태 판단 기준:

항목	정상 예시
GPU 목록	전체 GPU 표시
Driver Version	정상 표시
CUDA Version	정상 표시
GPU-Util	상황에 따라 0% 가능
Memory-Usage	비정상 점유 없는지 확인
Processes	불필요한 프로세스 없는지 확인

GPU가 정상 출력되면 GPU 드라이버 자체 장애 가능성은 낮아집니다.

---

9-13. Docker/메모리 원인 여부 확인

Docker 관련 로그:

journalctl --since "30 min ago" | egrep -i "docker|containerd|buildkit|runc|container"

OOM 확인:

dmesg -T | egrep -i "oom|out of memory|killed process|memory cgroup"

메모리 확인:

free -h

CPU/load 확인:

uptime

실시간 상태:

vmstat 1 5

---

10. 장애 조치 순서 🚑

1단계: systemctl 자체 timeout 여부 확인

timeout 5 systemctl is-system-running
timeout 5 systemctl --failed
timeout 5 busctl list | head

---

2단계: I/O hang 여부 확인

ps -eo state,pid,ppid,comm,wchan:30 | awk '$1 ~ /D/ {print}'

timeout 5 df -h

---

3단계: Lustre/LNet/IB 로그 확인

dmesg -T | egrep -i "lustre|lnet|o2ib|ptlrpc|mlx5|ib|infiniband|transport endpoint|hung|blocked"

---

4단계: systemd 재실행 시도

systemd 자체 응답이 불안정하면 아래 명령을 시도할 수 있습니다.

systemctl daemon-reexec

이 명령은 systemd PID 1을 재실행합니다.
전체 서버 리부팅보다 영향은 작지만 운영 중인 서버에서는 주의해서 사용해야 합니다.

---

5단계: slurmd 재시작

systemctl restart slurmd

상태 확인:

systemctl status slurmd

---

6단계: Slurm 노드 drain

반복 장애가 있으면 먼저 스케줄링에서 제외합니다.

scontrol update nodename=gpu-node01 state=drain reason="systemd dbus timeout / lustre client unstable"

---

7단계: 리부팅

systemctl, D-Bus, Lustre client, LNet 상태가 꼬였고 명령어 응답이 계속 느리면 리부팅이 가장 빠른 복구 방법일 수 있습니다.

reboot

복구 후 확인:

systemctl is-system-running
systemctl status slurmd
nvidia-smi
ibstat
lctl get_param health_check

Slurm 복귀:

scontrol update nodename=gpu-node01 state=resume

---

11. 여러 노드 동시 발생 여부 확인 🌐

한 노드만 문제인지, 여러 노드에서 동시에 발생했는지 확인해야 합니다.

예시:

clush -w gpu-node[01-64] "journalctl -k --since '2026-06-14 00:10' --until '2026-06-14 00:30' | egrep -i 'ptlrpc_expire|peer NIs in recovery|Connection to .* was lost|o2ib' | wc -l"

결과 해석:

결과	의미
특정 노드만 발생	해당 노드의 IB/Lustre client 문제 가능성
여러 노드 동시 발생	스토리지 서버, IB 스위치, 공통 경로 문제 가능성
특정 OST만 반복	해당 OST/OSS 또는 해당 경로 문제 가능성

---

12. 장애 원인 📝

해당 장애는 GPU 또는 Docker 직접 장애라기보다는, 일부 GPU 노드에서 systemctl 명령 수행 시 org.freedesktop.systemd1 D-Bus 응답 timeout이 발생한 건입니다. 동일 시간대에 Lustre/LNet 계층에서 peer NIs in recovery, ptlrpc request timeout, OST connection lost/restored 로그가 확인되어 Lustre over InfiniBand 경로의 순간적인 통신 지연 또는 클라이언트 세션 불안정이 systemd/journald 응답 지연으로 이어진 것으로 추정됩니다. 리부팅 후 정상화된 점을 고려하면 스토리지 서버 전체 장애보다는 해당 노드의 Lustre client, LNet/RDMA, systemd/D-Bus 상태가 일시적으로 비정상화되었다가 초기화되며 복구된 사례로 판단됩니다.

---

13. 최종 정리 ✅

이번 장애를 한 줄로 요약하면 다음과 같습니다.

Lustre/InfiniBand 통신이 순간적으로 불안정해지면서 노드 내부 I/O와 systemd/D-Bus 응답이 지연되었고, 그 결과 systemctl timeout이 발생한 장애입니다.

초보자 관점에서는 이렇게 이해하면 됩니다.

Lustre = 원격 고성능 스토리지
InfiniBand = 고속 네트워크
LNet = Lustre가 네트워크를 쓰는 계층
systemd = Linux 서비스 관리자
D-Bus = systemctl과 systemd가 대화하는 통신 통로
systemctl timeout = systemd에게 물어봤는데 답이 늦거나 안 온 상태

리부팅 후 해결됐다면 단순히 “Lustre 서버 전체 장애”라기보다는,

특정 노드의 Lustre client / LNet / IB / systemd-D-Bus 상태 꼬임

가능성이 높습니다.

장애가 재발하면 가장 먼저 아래 4가지를 확인하는 것이 좋습니다.

timeout 5 systemctl is-system-running
timeout 5 busctl list | head
ps -eo state,pid,ppid,comm,wchan:30 | awk '$1 ~ /D/ {print}'
dmesg -T | egrep -i "lustre|lnet|o2ib|ptlrpc|mlx5|ib|transport endpoint|hung|blocked"