아무도 책임지고 싶어 하지 않는 Systemd 버그

발행: 3일 전 (2026년 2월 28일 오전 04:18 GMT+9)

7 분 소요

I’m happy to translate the article for you, but I’ll need the full text you’d like translated. Could you please paste the content (excluding the source line you already provided) here? Once I have the text, I’ll translate it into Korean while preserving the original formatting, markdown, and technical terms.

Source:

TL;DR

Ubuntu 20.04, 22.04, 24.04 서버에 영향을 주는 네임스페이스 버그가 있어 무작위 서비스 장애가 발생합니다. 이 버그는 2021년부터 systemd, Ubuntu, Fedora, Red Hat 트래커에 보고되었습니다. 대부분의 보고서는 만료되었거나 “not‑our‑bug”으로 표시되었습니다. 재부팅만이 해결책입니다.

Ubuntu 서버를 운영 중이며 로그에서 다음과 같은 메시지를 본 적이 있다면:

Failed to set up mount namespacing: /run/systemd/unit-root/dev: Invalid argument
Failed at step NAMESPACE spawning: Invalid argument
Main process exited, code=exited, status=226/NAMESPACE

축하합니다. 여러분은 Linux 생태계에서 가장 답답한 버그 중 하나를 경험한 것입니다 — 커널 팀과 systemd 팀 사이를 오가며 수년간 해결되지 않은 버그입니다.

What Happens

무작위 systemd 서비스(예: systemd-resolved, systemd-timesyncd, systemd-journald와 같은 중요한 서비스 및 사용자 정의 서비스)가 갑자기 시작을 거부합니다. 오류 메시지에 “mount namespacing” 및 “Invalid argument”가 표시됩니다.

서비스를 재시작해도 도움이 되지 않습니다.
systemctl daemon-reload를 실행해도 도움이 되지 않습니다.
유일하게 확실한 해결 방법은 시스템을 완전히 재부팅하는 것입니다.

컨테이너 기반 워크로드(LXC, LXD, Proxmox)를 실행 중이라면 상황이 더 악화됩니다. 이 버그는 전체 호스트 노드에 영향을 미칠 수 있으며, 컨테이너를 재부팅해도 문제를 해결할 수 없습니다 — 하이퍼바이저 자체를 재부팅해야 합니다.

The Blame Game

저는 이 버그를 여러 이슈 트래커에서 추적했습니다:

systemd/systemd #24798 — Ubuntu 20.04, 2022년 9월
systemd/systemd #19926 — not-our-bug 라벨, 2021년 6월
Ubuntu Launchpad #1990659 — 비활동으로 인해 만료됨
Fedora CoreOS #1296 — PXE/디스크리스 부팅에 영향
Red Hat Bugzilla #2111863 — Jira로 마이그레이션, 상태 미확인
dbus-broker #297 — CentOS Stream 9

패턴은 언제나 같습니다: 사용자가 버그를 보고하고, 유지관리자는 디버그 로그를 요청합니다. 버그는 “not‑our‑bug”으로 종료되거나 만료됩니다. systemd 팀은 커널 문제라고 말하고, 커널 팀… 글쎄요, 커널 팀에서 이 문제를 적극적으로 조사하고 있는 사람을 찾지 못했습니다.

근본 원인 (가능한 한 최선의 추정)

경쟁 조건이 마운트‑네임스페이스 설정에 존재 — systemd가 다른 언마운트 작업이 진행 중일 때 /sys와 /dev를 다시 마운트하려고 함.
마운트 전파 문제 — systemd가 기본값을 MS_PRIVATE에서 MS_SHARED로 변경하여 예상치 못한 상호 작용을 일으킴.
자원 고갈 — 때때로 inotify 제한(fs.inotify.max_user_instances)과 관련됨.
컨테이너/가상화 엣지 케이스 — LXC/LXD 환경에서 더 흔히 나타남.

아직 확정적인 근본 원인 분석을 수행한 사람은 없습니다. 이 버그는 간헐적이며, 요구에 따라 재현하기 어렵고, 몇 주 또는 몇 달 동안 정상적으로 운영되어 온 시스템에도 영향을 미칩니다.

Source:

The Irony

Remember when /etc/init.d/ scripts “just worked”? When starting a service meant running a shell script that executed a binary?

Systemd brought us dependency management, socket activation, cgroups integration, and dozens of security features like PrivateDevices=, ProtectSystem=, and PrivateTmp=. These are genuinely useful features.

But they also introduced complexity. The namespace isolation that causes this bug exists because systemd creates a private mount namespace for services with security hardening enabled. It’s a feature. Until it breaks.

The old init system didn’t have this bug because it didn’t have namespaces. Services ran in the global namespace. Less secure? Yes. But also fewer moving parts to fail.

워크어라운드

1. 영향을 받는 서비스에 대한 네임스페이스 격리 비활성화

sudo systemctl edit your-service.service

다음 오버라이드를 추가합니다:

[Service]
PrivateDevices=no
ProtectHome=no
ProtectSystem=no

2. 손상된 systemd 상태 정리

sudo rm -rf /run/systemd/unit-root/
sudo systemctl daemon-reload

3. inotify 제한 증가

echo "fs.inotify.max_user_instances=512" | sudo tee -a /etc/sysctl.conf
sudo sysctl -p

4. 모니터링 및 자동 재시작

* */3 * * * systemctl list-units --failed | grep -q NAMESPACE && reboot

네, 마지막 항목은 예약된 재부팅입니다. 현재 상황이 바로 그 정도입니다.

무엇이 일어나야 하는가

신뢰할 수 있는 재현 사례를 만든다.
실패가 발생했을 때 정확한 커널/시스템드 상태를 캡처할 수 있도록 계측을 추가한다.
적절한 근본 원인 분석을 수행한다.
커널, 시스템드, 혹은 둘 다에서 수정한다.

그때까지는 우리 모두 서버를 재부팅하고 운에 맡길 뿐이다.

이 버그를 경험해 보셨나요? 해결 방법은 무엇인가요? 더 깊이 조사했거나 영구적인 해결책을 찾은 분들의 이야기를 듣고 싶습니다.