systemd RemainAfterExit 기준 정리

systemd RemainAfterExit 기준 정리

RemainAfterExit=는 서비스에 속한 모든 프로세스가 종료된 뒤에도 systemd가 그 서비스를 active 상태로 볼지 정하는 옵션이다. 2026년 7월 25일 확인 기준 systemd 공식 systemd.service 매뉴얼은 기본값이 no라고 설명한다.

실무에서는 일회성 설정 작업, 마운트 전후 처리, 장치 초기화처럼 명령은 끝나지만 "적용된 상태" 자체는 유지된다고 보고 싶은 서비스에서 자주 검토한다. 이 글은 systemd 261.2 공식 문서를 기준으로 Type=oneshot과의 관계, ExecStop= 패턴, ExitType=과의 차이, 선택 시 주의점을 정리한다.

RemainAfterExit는 정확히 무엇을 바꿀까?

핵심은 프로세스 생존 여부와 unit 활성 상태를 분리한다는 점이다. 보통 서비스는 메인 프로세스가 끝나면 inactive나 failed로 이동한다. 반면 RemainAfterExit=yes를 주면 관련 프로세스가 모두 끝난 뒤에도 unit은 active 상태로 남을 수 있다.

즉 이 옵션은 백그라운드 프로세스를 더 오래 실행하게 만드는 기능이 아니다. 이미 종료된 작업을 systemd가 "적용된 상태로 유지 중"이라고 해석하게 만드는 쪽에 가깝다.

왜 Type=oneshot과 함께 자주 언급될까?

systemd 공식 문서는 Type=oneshot이 메인 프로세스가 종료된 뒤에야 unit을 up으로 간주한다고 설명한다. 그리고 같은 문서는 RemainAfterExit=가 이 타입에서 특히 유용하다고 안내한다.

이유는 간단하다. Type=oneshot 서비스는 계속 실행될 프로세스가 없기 때문에, RemainAfterExit=를 주지 않으면 실행 직후 active 상태를 유지하지 못한다. 공식 문서는 이 경우 unit이 activating에서 곧바로 deactivating 또는 dead로 넘어가며, 실행 후에도 started 상태로 보이지 않는다고 설명한다.

[Service]
Type=oneshot
ExecStart=/usr/bin/example-setup
RemainAfterExit=yes

언제 쓰는 편이 자연스러울까?

한 번 실행해서 상태를 만들어 두고, 나중에 stop 시점에 대응 동작을 하고 싶은 경우가 대표적이다. 예를 들어 방화벽 규칙 적용, 특정 가상 장치 준비, 외부 시스템에 등록 작업 수행처럼 start 단계 명령은 끝나지만 효과는 남아 있는 작업이 여기에 가깝다.

반대로 장기 실행 프로세스를 관리하는 데몬이라면 보통 이 옵션이 핵심이 아니다. 공식 문서는 장기 실행 서비스에는 대체로 Type=exec, notify, notify-reload, dbus 쪽을 우선 검토하라고 설명한다.

ExecStop= 패턴과는 어떤 관계가 있을까?

공식 문서는 ExecStart=가 없는 서비스는 반드시 RemainAfterExit=yes와 최소 하나의 ExecStop=를 가져야 한다고 설명한다. 즉 systemd는 "지금은 실행할 시작 명령이 없지만, active 상태로 간주되는 작업을 stop 시점에 정리할 수 있다"는 모델을 허용한다.

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/usr/bin/firewall-cmd --reload
ExecStop=/usr/bin/firewall-cmd --complete-reload

실무적으로는 이 패턴이 start와 stop을 짝으로 다루는 선언형 래퍼 역할을 한다. 다만 실제 ExecStop= 명령은 서비스 설계에 맞아야 하며, 단순히 옵션만 넣는다고 이전 상태가 자동 복구되는 것은 아니다.

ExitType=과는 무엇이 다를까?

RemainAfterExit=는 "프로세스가 없어도 active로 볼 수 있는가"를 정한다. 반면 ExitType=은 "언제 서비스를 끝난 것으로 볼 것인가"를 정한다. systemd 공식 문서 기준 기본값은 ExitType=main이고, cgroup을 쓰면 cgroup 안의 프로세스가 하나라도 남아 있는 동안 running으로 본다.

중요한 차이는 ExitType=cgroup은 실제 남아 있는 프로세스를 기준으로 한다는 점이고, RemainAfterExit=yes는 프로세스가 모두 끝난 뒤에도 active 상태를 유지할 수 있다는 점이다. 또 공식 문서는 ExitType=cgroup을 Type=oneshot과 함께 쓸 수 없다고 명시한다.

백그라운드 프로세스를 감추는 용도로 쓰면 왜 곤란할까?

RemainAfterExit=yes는 systemd의 추적 모델을 대체하지 않는다. 서비스가 다른 자식 프로세스를 띄운 뒤 메인 명령만 종료되는 구조라면, 우선 그 서비스의 실제 타입과 메인 프로세스 식별 방식을 다시 보는 편이 안전하다.

공식 문서도 현대적인 서비스에는 가능하면 PIDFile= 의존을 줄이고 Type=notify, notify-reload, simple 등을 우선 검토하라고 안내한다. 그래서 long-running daemon을 RemainAfterExit=yes로 "켜진 것처럼만" 보이게 만드는 설계는 보수적으로 봐야 한다.

선택 기준을 짧게 정리하면?

첫째, start 명령이 끝난 뒤에도 논리적으로 유지되는 상태가 있는지 본다. 둘째, 서비스가 실제 데몬을 추적해야 하는지, 아니면 일회성 작업의 적용 상태만 표현하면 되는지 구분한다. 셋째, stop 시점에 되돌리기나 정리 동작이 필요한지 확인한다.

대부분의 장기 실행 서비스는 RemainAfterExit=보다 적절한 Type= 선택이 먼저다. 반대로 일회성 작업이지만 active 상태를 유지해야 이후 의존성이나 stop 동작이 자연스러운 경우에는 Type=oneshot과 RemainAfterExit=yes 조합이 잘 맞는다.

FAQ

Q. RemainAfterExit=yes를 주면 프로세스가 계속 살아 있나?

아니다. 공식 문서 기준 이 옵션은 프로세스 생존을 강제하지 않는다. 프로세스가 모두 끝난 뒤에도 unit을 active로 볼지를 정할 뿐이다.

Q. Type=oneshot인데 RemainAfterExit를 안 주면 어떻게 되나?

공식 문서는 이 경우 실행 후 active 상태를 유지하지 못하고 곧바로 deactivating 또는 dead로 간다고 설명한다. 그래서 "한 번 실행됐고 지금도 적용 상태로 본다"는 의미를 남기고 싶다면 보통 yes가 필요하다.

Q. long-running daemon에도 써도 되나?

기술적으로 설정은 가능해도, 공식 문서의 권장 방향은 별개다. 장기 실행 서비스는 보통 적절한 Type=과 메인 프로세스 추적을 먼저 맞추는 편이 자연스럽다.

정리

RemainAfterExit=의 의미는 "프로세스가 끝난 뒤에도 서비스의 논리 상태를 active로 유지할 것인가"에 있다. 일회성 설정 작업처럼 효과는 남고 프로세스는 끝나는 서비스에는 잘 맞지만, 장기 실행 데몬의 추적 문제를 덮는 해결책으로 쓰기에는 맞지 않는다.

대부분의 판단 기준은 단순하다. 프로세스를 추적해야 하면 적절한 Type=과 준비 완료 신호를 고르고, 적용 상태만 남기면 되는 oneshot 작업이면 RemainAfterExit=yes를 검토하면 된다.

참고 자료

• systemd.service
• systemd.unit