systemd BindsTo 기준 정리

systemd BindsTo 기준 정리

systemd에서 두 유닛을 함께 묶고 싶을 때 Requires=만으로 충분한지, 아니면 더 강한 관계가 필요한지 헷갈릴 때가 많다. 2026년 7월 24일 기준 systemd 공식 systemd.unit 문서를 보면 BindsTo=는 Requires=보다 강한 의존성으로, 상대 유닛이 예기치 않게 inactive가 되는 상황까지 현재 유닛에 영향을 준다.

이 글은 공식 문서를 기준으로 BindsTo=가 정확히 무엇을 보장하는지, 왜 보통 After=와 함께 쓰는지, Requires=와 어떤 차이가 있는지, 그리고 device unit과 연결할 때 무엇을 확인해야 하는지 정리한다.

BindsTo=는 무엇을 할까?

공식 문서에 따르면 BindsTo=는 요구 의존성을 설정하는 점에서는 Requires=와 비슷하지만, 효과가 더 강하다. 상대 유닛이 명시적으로 정지되거나 재시작될 때만이 아니라, 예상치 않게 inactive 상태로 바뀌는 경우에도 현재 유닛이 함께 멈출 수 있다.

문서가 예로 드는 unexpected inactive 상황에는 서비스 프로세스가 스스로 종료하는 경우, device unit의 실제 장치가 제거되는 경우, mount unit이 systemd를 거치지 않고 언마운트되는 경우가 포함된다. 따라서 핵심은 "같이 시작한다"보다 "상대가 사라지면 나도 살아 있지 않는다"에 가깝다.

Requires=와는 무엇이 다를까?

공식 systemd.unit 문서는 Requires=가 더 강한 시작 의존성이지만, 상대 유닛이 항상 active 상태여야 한다는 뜻은 아니라고 설명한다. 예를 들어 조건 검사 실패로 유닛이 건너뛰어지거나, 서비스가 스스로 종료하거나, 장치가 unplug 되는 상황은 Requires=만으로 현재 유닛에 그대로 전파되지 않는다.

반면 문서는 이런 상황까지 현재 유닛을 강하게 묶고 싶다면 BindsTo=와 After=를 함께 쓰라고 분명히 안내한다. 즉 Requires=는 "같이 끌어온다"에 더 가깝고, BindsTo=는 "활성 상태를 분리하지 않는다"에 더 가깝다.

옵션	공식 문서상 의미	실무에서 보는 기준
Wants=	약한 요구 의존성	같이 시작은 원하지만 상대 실패를 강하게 전파하고 싶지 않을 때
Requires=	강한 요구 의존성	시작 시 함께 끌어오고, 명시적 정지·재시작은 연동하지만 예기치 않은 비활성화까지 강제하지는 않을 때
BindsTo=	Requires=보다 강한 결합	상대 유닛이 없어지거나 건너뛰어지는 상황까지 현재 유닛을 같이 내리고 싶을 때
PartOf=	정지와 재시작만 전파	활성 상태까지 강하게 묶지 않고 운영 동작만 따라오게 하고 싶을 때

왜 보통 After=를 같이 쓸까?

공식 문서는 Wants=, Requires=, BindsTo= 같은 요구 의존성과 After=, Before= 같은 순서 의존성이 서로 독립적이라고 설명한다. 즉 BindsTo=만 넣어도 순서가 자동으로 생기지는 않는다.

BindsTo=가 After=와 같이 쓰일 때는 의미가 더 강해진다. 문서에 따르면 이 경우 상대 유닛이 실제로 active 상태여야 현재 유닛도 active 상태가 될 수 있다. 상대 유닛이 조건 검사 실패로 건너뛰어진 경우에도 현재 유닛이 계속 살아 있지 않도록 만들 수 있다는 뜻이다.

따라서 "같은 대상에 묶이고, 시작 순서도 그 뒤를 따르고, 상대가 빠지면 나도 내려가야 한다"는 요구라면 다음처럼 역할을 나눠 적는 편이 문서 의미와 맞다.

[Unit]
BindsTo=data.mount
After=data.mount

device unit과 연결할 때는 무엇이 중요할까?

공식 systemd.device 문서에 따르면 device unit은 커널 장치가 udev에 의해 노출될 때 systemd가 동적으로 만든다. 장치가 사라질 수 있는 특성 때문에 BindsTo=가 특히 의미를 갖는 대상이 device unit이다.

문서는 또한 일부 유닛이 장치에 기대는 경우 자동 의존성이 추가된다고 설명한다. 예를 들어 .socket 유닛에서 BindToDevice=를 쓰면 해당 네트워크 인터페이스의 device unit에 대한 의존성이 생긴다. 이런 구조를 이해하면, 장치 생명주기와 서비스 생명주기를 강하게 묶어야 하는지 판단하기 쉬워진다.

한 가지 더 볼 점은 순서 제어의 한계다. 공식 systemd.unit 문서는 device unit에 대한 Before=는 효과가 없고 지원되지 않는다고 설명한다. 장치는 외부 hotplug 이벤트로 나타나기 때문에, device unit과의 관계는 보통 After= 중심으로 생각하는 편이 맞다.

설정 결과는 어떻게 확인할까?

공식 문서에 따르면 a.service에 BindsTo=b.service를 설정하면, b.service의 속성 목록에는 자동 속성인 BoundBy=a.service가 표시된다. BoundBy=는 직접 설정하는 옵션이 아니라 역방향 관계를 보여 주는 속성이다.

확인할 때는 다음 정도면 충분하다.

systemctl show current.service -p BindsTo
systemctl show target.service -p BoundBy

여기서 중요한 것은 "설정 파일에 무엇을 썼는가"보다 "매니저가 현재 어떤 관계로 이해하고 있는가"다. 직접 유닛 파일을 수정한 직후라면 매니저가 새 정의를 다시 읽었는지도 함께 점검해야 혼동이 줄어든다.

언제 BindsTo=가 잘 맞을까?

BindsTo=는 상대 유닛이 inactive가 되는 순간 현재 유닛도 함께 내려가야 할 때 적합하다. 예를 들어 특정 마운트가 사라지면 유지할 이유가 없는 서비스, 특정 장치가 빠지면 계속 실행하면 안 되는 수집기나 watcher가 여기에 가깝다.

반대로 단순히 메인 서비스 재시작 때 보조 유닛도 따라 재시작되면 충분한 경우라면 PartOf=가 더 목적에 맞을 수 있다. 또 시작 단계에서 함께 pull-in만 필요하고 상대 실패를 전체 트랜잭션 실패로까지 몰고 가고 싶지 않다면 Wants=가 더 무난할 수 있다.

자주 묻는 질문

Q. BindsTo=만 넣으면 시작 순서도 자동으로 맞춰질까?

아니다. 공식 문서는 요구 의존성과 순서 의존성이 독립적이라고 설명한다. 시작 순서가 중요하면 같은 대상에 대해 After= 또는 Before=를 별도로 설정해야 한다.

Q. Requires=가 있는데도 왜 BindsTo=가 더 필요할 수 있을까?

Requires=만으로는 상대 유닛의 조건 검사 실패나 예기치 않은 비활성화가 현재 유닛에 그대로 전파되지 않을 수 있기 때문이다. 공식 문서는 이런 경우 현재 유닛이 상대 유닛 없이 active 상태로 남을 수 있다고 설명하고, 그 차이를 메우는 수단으로 BindsTo=를 제시한다.

Q. device unit에는 Before=를 써도 될까?

공식 systemd.unit 문서는 device unit에 대한 Before=는 지원되지 않고 효과도 없다고 설명한다. device unit과 관계를 잡을 때는 보통 After=를 검토하는 편이 더 현실적이다.

정리

BindsTo=는 systemd에서 두 유닛의 활성 상태를 강하게 묶는 옵션이다. Requires=보다 강하며, 상대 유닛이 예기치 않게 inactive가 되거나 조건 검사 때문에 건너뛰어지는 상황까지 현재 유닛에 반영하고 싶을 때 의미가 있다.

2026년 7월 24일 기준 공식 문서를 기준으로 보면, 실무 포인트는 단순하다. 시작 pull-in은 Wants=나 Requires=, 순서는 After=, 정지·재시작 전파는 PartOf=, 상대 유닛 없이 active 상태가 남지 않게 하려면 BindsTo=를 우선 검토하면 된다.

참고 자료

• systemd 공식 문서: systemd.unit
• systemd 공식 문서: systemd.device