systemd PartOf 기준 정리

본문 중간의 쿠팡 추천 상품 구매시 쿠팡 파트너스에서 일정액의 수수료를 제공받습니다.

systemd PartOf 기준 정리

systemd에서 여러 유닛을 함께 운영하다 보면 "이 유닛을 멈추거나 다시 시작할 때 다른 유닛도 같이 따라오게 할 수 있을까?"라는 질문이 자주 나온다. 2026년 7월 20일 기준 systemd 공식 systemd.unit 문서를 보면 PartOf=는 바로 이 상황을 위한 의존성으로, 시작이 아니라 정지와 재시작 전파를 다루는 옵션이다.

이 글은 공식 문서를 기준으로 PartOf=가 정확히 무엇을 전파하는지, Wants=·Requires=·BindsTo=와 무엇이 다른지, 그리고 실제 점검 때 systemctl show와 list-dependencies를 어떻게 보면 되는지 정리한다.

PartOf=는 무엇을 할까?

공식 문서에 따르면 PartOf=는 Requires=와 비슷한 종류의 관계를 만들지만, 범위가 정지와 재시작으로 제한된다. 즉 어떤 유닛에 PartOf=parent.service를 설정하면, systemd가 parent.service를 멈추거나 다시 시작할 때 그 동작이 현재 유닛으로 전파된다.

중요한 점은 이 관계가 단방향이라는 사실이다. 문서는 현재 유닛의 변화가 나열된 대상 유닛에 영향을 주지 않는다고 설명한다. 따라서 worker.service에 PartOf=app.service를 넣었다고 해서 worker.service를 재시작할 때 app.service가 같이 재시작되지는 않는다.

시작까지 같이 따라오지는 않을까?

공식 문서 설명은 PartOf=를 정지와 재시작에 한정한다. 반면 systemd 문서는 시작 시 다른 유닛을 끌어오는 관계를 Wants=와 Requires=로 따로 설명한다. 이 둘을 함께 보면, 시작 연동이 필요할 때는 PartOf=만으로는 부족하고 시작용 의존성을 별도로 둬야 한다고 해석하는 것이 자연스럽다.

예를 들어 어떤 보조 서비스가 메인 서비스와 함께 시작되어야 하고, 메인 서비스가 재시작될 때도 같이 재시작되어야 한다면 다음처럼 역할을 나누는 방식이 맞다.

[Unit]
Wants=app.service
After=app.service
PartOf=app.service

여기서 Wants=는 시작 시 pull-in을, After=는 순서를, PartOf=는 정지와 재시작 전파를 맡는다. 공식 문서 기준으로 각 옵션의 역할이 다르기 때문에, 어느 하나를 다른 하나의 대체재로 보면 헷갈리기 쉽다.

Requires=, BindsTo=와는 무엇이 다를까?

옵션	공식 문서상 핵심 의미	실무에서 보는 포인트
Wants=	약한 시작 의존성	같이 올리고 싶지만 실패를 강하게 전파하고 싶지 않을 때
Requires=	더 강한 시작 의존성	명시적 정지·재시작은 전파되지만, 상대 유닛이 예기치 않게 비활성화되는 상황까지 강제하지는 않음
BindsTo=	Requires=보다 강한 결합	상대 유닛이 예상치 않게 inactive가 되면 현재 유닛도 멈추게 하고 싶을 때
PartOf=	정지와 재시작만 전파	메인 유닛의 운영 동작에 보조 유닛을 묶고 싶지만 활성 상태까지 강하게 결합하고 싶지는 않을 때

공식 문서에서 특히 구분이 분명한 부분은 BindsTo=다. BindsTo=는 명시적 정지와 재시작뿐 아니라 상대 유닛이 예기치 않게 inactive가 되는 경우까지 현재 유닛에 영향을 준다. 따라서 단순히 "같이 재시작"만 원한다면 PartOf=가 더 약하고 목적에 맞는 선택일 수 있다.

순서는 어떤 옵션으로 맞출까?

systemd 공식 문서는 Before=와 After=가 유닛 사이의 순서를 정하는 옵션이라고 설명한다. 시작 순서뿐 아니라 종료 시에는 그 역순이 적용되며, 어떤 유닛을 내리면서 다른 유닛을 올리는 경우에도 정지 작업이 시작 작업보다 먼저 처리된다.

따라서 "같이 재시작"과 "어느 쪽이 먼저 멈추고 먼저 올라와야 하는가"는 다른 문제다. 재시작 전파는 PartOf=가 맡고, 실제 순서는 After= 또는 Before=로 따로 표현하는 편이 문서의 의미와 맞다.

설정 결과는 어디서 확인할까?

공식 systemd.unit 문서는 PartOf=를 설정하면 반대편 속성으로 ConsistsOf=가 자동 생성된다고 설명한다. 예를 들어 a.service에 PartOf=b.service를 넣으면, b.service의 속성 목록에는 ConsistsOf=a.service가 보인다. 이 값은 직접 설정하는 항목이 아니라 자동 속성이다.

확인할 때는 다음 명령이 가장 단순하다.

systemctl show app.service -p ConsistsOf
systemctl show worker.service -p PartOf

또한 공식 systemctl 문서는 list-dependencies가 재귀적으로 ConsistsOf=를 따라가 보여 준다고 설명한다. 반대로 --reverse를 주면 PartOf= 같은 역방향 관계를 따라가며 확인할 수 있다. 구성 검증 시 트리로 훑어보기 좋다.

 

 

언제 PartOf=가 잘 맞을까?

PartOf=는 메인 서비스의 생명주기에 보조 유닛을 맞추고 싶을 때 잘 맞는다. 예를 들어 메인 데몬이 재시작될 때 같이 내려갔다가 다시 올라와야 하는 캐시 워머, 보조 watcher, sidecar 성격의 서비스가 여기에 가깝다.

반대로 상대 유닛이 비정상 종료하거나 조건 검사 실패로 건너뛰는 상황까지 현재 유닛을 강하게 묶고 싶다면, 공식 문서 기준으로는 BindsTo=와 After= 조합을 먼저 검토하는 편이 더 가깝다. 목적이 "같이 운영"인지, "활성 상태를 절대 분리하지 않기"인지 구분하는 것이 핵심이다.

자주 묻는 질문

Q. PartOf=만 넣으면 부모 유닛 시작 시 자식도 자동으로 시작될까?

공식 문서 설명만 놓고 보면 PartOf=는 정지와 재시작 전파에 한정된다. 시작 시 자동 pull-in이 필요하면 Wants= 또는 Requires= 같은 시작 의존성을 함께 검토해야 한다.

Q. PartOf=는 양방향 관계일까?

아니다. systemd 문서는 이 관계가 one-way dependency라고 명시한다. 나열된 대상 유닛의 변화가 현재 유닛으로 전파될 뿐, 현재 유닛의 변화가 대상 유닛으로 되돌아가지는 않는다.

Q. 설정 파일을 바꾼 뒤 왜 바로 동작이 안 보일까?

공식 systemctl 문서에 따르면 디스크의 유닛 파일이 바뀌었는데 매니저가 아직 다시 읽지 않았다면, 화면에 보이는 정보와 실제 매니저가 이해한 상태가 다를 수 있다. 직접 유닛 파일을 수정했다면 systemctl daemon-reload가 필요한지 함께 확인하는 편이 안전하다.

정리

PartOf=는 systemd에서 유닛 간 정지와 재시작을 전파하는 데 쓰는 옵션이다. 시작을 끌어오는 용도는 Wants=나 Requires=, 순서 제어는 After=와 Before=, 예기치 않은 비활성화까지 강하게 묶는 용도는 BindsTo=가 맡는다.

2026년 7월 20일 기준 공식 문서를 기준으로 보면, PartOf=는 "같이 멈추고 같이 재시작"이라는 운영 관계를 가장 단순하게 표현할 때 유용하다. 다만 시작 연동과 순서까지 한 번에 해결해 주는 옵션은 아니므로, 필요한 의존성을 역할별로 분리해서 적는 편이 더 정확하다.

참고 자료

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