---
date: 2026-05-20
topic: kr2 multus-shim ETXTBSY 데드락 — k3s 재시작 후 CNI 복구 불가
areas: [infra/compute/infra-hosts, infra/platform]
---

# 2026-05-20 / kr2 multus-shim ETXTBSY 데드락

## 증상

`/sc:test` 와 무관, NAS NFS 점검 중 발견. kr2 노드는 K8s `Ready` 인데 노드 위 Pod 8개가 stuck:

- `Unknown`: traefik, kube-multus-ds, kube-system/descheduler, vector, longhorn-manager / longhorn-csi-plugin / engine-image
- `ContainerCreating` 장시간 (16–29h): critical-backup, critical-snapshot, descheduler

`kubelet` 에러:

```
plugin type="multus-shim" name="multus-cni-network" failed (add):
CmdAdd (shim): timed out waiting for the condition
```

## 데드락 구조

1. 2026-05-19 11:11:59 KST kr2 `k3s.service` 재시작 직후 `kube-multus-ds` Pod이 init 단계에서 깨끗하게 복구 안 됨.
2. `install-multus-binary` initContainer 가 `cp` 로 `/host/opt/cni/bin/multus-shim` 갱신 시도 → `cp: cannot create regular file '/host/opt/cni/bin/multus-shim': Text file busy` (**ETXTBSY**).
3. ETXTBSY 원인: kubelet 이 stuck Pod sandbox 재생성 시도 → `/opt/cni/bin/multus-shim` 을 자식 프로세스로 spawn → multus daemon socket 부재로 RPC hang → shim 프로세스가 inode 잡은 채로 매달림.
4. shim 누적 (관찰 시 8 → 14 → 매달림 지속). cp 는 영원히 fail. multus daemon 영원히 안 뜸. **완전한 데드락.**
5. `pkill -9 multus-shim`, `fuser -k` 모두 즉시 새 shim 이 spawn 되어 효과 없음. `systemctl restart k3s` 도 마찬가지 — 재시작 후 kubelet 이 sandbox cleanup retry 하면서 shim 다시 누적.

## 해결 키

```bash
sudo rm /opt/cni/bin/multus-shim
```

`unlink(2)` 는 매달린 프로세스의 fd 가 잡고 있는 inode 를 보존한 채 path 만 제거. 다음 `install-multus-binary` retry 의 `cp` 는 **fresh inode** 로 새 파일 생성 → ETXTBSY 회피 → multus daemon 정상 기동 → 매달린 shim 들이 응답 받고 자연 종료.

## 복구 절차 (실제 수행)

```bash
# 1. stuck pod force delete (kubelet retry 루프 끊기)
kubectl delete pod --force --grace-period=0 -n kube-system descheduler-* traefik-*
kubectl delete pod --force --grace-period=0 -n logging vector-*
kubectl delete pod --force --grace-period=0 -n longhorn-system \
  critical-{backup,snapshot}-* engine-image-* longhorn-{csi-plugin,manager}-*

# 2. kr2 호스트에서 multus-shim 파일 unlink (핵심)
ssh kaffa@kr2 'sudo rm /opt/cni/bin/multus-shim'

# 3. multus DS pod 재생성 → backoff 카운터 리셋
kubectl delete pod -n kube-system kube-multus-ds-<crashing-pod> --force --grace-period=0
```

3분 내 모든 stuck Pod 정상화. 잔여 shim 0개 자동 정리. instance-manager 등 cascade로 띄워지는 Pod도 자동 복구.

## 검증

```
NAMESPACE         NAME                  READY   STATUS      RESTARTS  AGE
kube-system       kube-multus-ds-9lxxn  1/1     Running     0         29s
kube-system       traefik-kjts5         1/1     Running     0         3m10s
kube-system       descheduler-...       0/1     Completed   0         3m10s
logging           vector-rc6ph          1/1     Running     0         3m9s
longhorn-system   engine-image-...      1/1     Running     0         3m9s
longhorn-system   instance-manager-...  1/1     Running     0         43s
longhorn-system   longhorn-csi-plugin-* 3/3     Running     0         3m9s
longhorn-system   longhorn-manager-*    2/2     Running     0         3m9s
longhorn-system   critical-snapshot-*   0/1     Completed   0         3m8s
```

전 클러스터 비정상 Pod 0개. 4 노드 모두 Ready.

## 교훈

- **ETXTBSY 데드락 패턴**: CNI plugin daemon이 정상 socket을 listen하지 않으면 kubelet retry가 shim을 누적 spawn → 바이너리 갱신 불가. 같은 패턴은 calico, cilium 등 다른 CNI 에서도 발생 가능.
- **`rm` 으로 unlink → fresh inode** 가 표준 회피책. `pkill` / `fuser -k` / 데몬 재시작 모두 retry 루프 못 끊음.
- **재발 방지**: kr2 k3s 재시작 시 `kube-multus-ds` 가 다시 init 단계에서 깨질 수 있음. 재시작 직후 60초 안에 multus DS Pod 상태 확인하고 backoff 회수가 빠르게 늘면 즉시 위 절차 적용.
- 발견 경위: NAS NFS 연결 점검 중 `kubectl get pods -A` 부수 확인에서 우연히 노출. NFS 점검과 인과 무관.

## 관련 문서

- [[infra-hosts]] — K3s 4 노드 구성 (kr1, kr2, hp1, hp2)
- [[longhorn]] — instance-manager / engine-image / manager / csi-plugin DS 구조
- multus CNI 공식: <https://github.com/k8snetworkplumbingwg/multus-cni>