systemd override.conf 사용법

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

systemd override.conf 사용법

systemctl edit는 systemd 유닛 파일을 직접 덮어쓰기보다 작은 변경만 분리해서 적용할 때 가장 먼저 떠올릴 도구다. 2026년 7월 5일 기준 systemd 261.1 공식 문서를 보면 기본 동작은 메인 유닛 파일을 바꾸는 것이 아니라 drop-in 파일을 만들거나 수정하는 방식이며, 기본 파일명은 override.conf다.

실무에서는 "패키지 업데이트를 따라가야 하는가", "전체 유닛을 교체해야 하는가", "재부팅 전까지만 임시로 바꿀 것인가"가 핵심 기준이다. 이 글은 systemctl edit, --full, --runtime, revert, drop-in 우선순위를 공식 문서 기준으로 정리한다.

systemctl edit는 무엇을 만들까?

방식	무엇이 만들어지나	언제 쓰나
기본 systemctl edit unit.service	drop-in 파일, 기본 이름은 override.conf	특정 설정 몇 개만 추가·변경할 때
systemctl edit --drop-in=name.conf unit.service	이름을 지정한 drop-in 파일	목적별 설정을 파일별로 나눌 때
systemctl edit --full unit.service	메인 유닛 파일 대체본	의존성 제거처럼 drop-in만으로 부족할 때

systemctl edit는 편집이 끝나면 설정을 다시 읽어 들인다. 공식 문서는 이 동작이 systemctl daemon-reload --system 또는 --user와 동등하다고 설명한다. 따라서 파일만 손으로 바꾼 뒤 재적용을 깜빡하는 상황을 줄이려면, 가능하면 편집도 systemctl edit 경로로 처리하는 편이 낫다.

왜 기본 방식은 drop-in일까?

공식 문서의 핵심 기준은 벤더 유닛 파일을 그대로 두고 필요한 설정만 덧붙이는 것이다. drop-in은 메인 유닛 파일이 먼저 파싱된 뒤 알파벳 순서로 추가 적용된다. 그래서 패키지 업데이트로 /usr/lib/systemd/system 아래 원본 유닛이 개선되더라도, 내가 바꾼 부분만 유지한 채 새 기본값을 함께 가져가기 쉽다.

반대로 --full로 메인 유닛 파일을 대체하면 벤더 쪽 원본 전체를 사실상 직접 관리하게 된다. 이는 일부 항목만 고치는 데는 과하고, 이후 배포판 패키지 업데이트가 들어와도 자동 반영되지 않는다는 부담이 있다.

drop-in 우선순위는 어떻게 결정될까?

systemd 261.1 공식 문서는 시스템 서비스 기준 drop-in을 /etc/systemd/system, /run/systemd/system, /usr/lib/systemd/system 아래에 둘 수 있고, 우선순위는 /etc가 가장 높고 그다음이 /run, 마지막이 /usr/lib라고 설명한다. 서로 다른 파일명은 디렉터리 위치와 상관없이 사전식 순서로 적용된다.

즉, 운영자가 장기 설정을 두려면 보통 /etc/systemd/system/unit.service.d/가 기준이 되고, 재부팅 시 사라져도 되는 임시 변경은 /run 아래 runtime drop-in이 어울린다.

systemctl edit nginx.service
systemctl edit --drop-in=limits.conf nginx.service
systemctl cat nginx.service

systemctl cat는 메인 fragment와 drop-in 소스 파일을 함께 보여 준다. 공식 문서는 단, 디스크 파일이 바뀌었는데 아직 daemon-reload를 하지 않았다면 실제 매니저가 이해한 내용과 화면 출력이 다를 수 있다고 경고한다.

--full이 필요한 경우는 언제일까?

drop-in은 설정 추가와 일부 값 재정의에 강하지만, 모든 변경을 다 처리할 수 있는 것은 아니다. 공식 문서 예시는 list 성격의 일반 설정은 빈 값으로 먼저 리셋한 뒤 새 값을 줄 수 있지만, After= 같은 dependency 계열은 drop-in에서 빈 목록으로 초기화할 수 없다고 설명한다. 이런 경우에는 전체 유닛을 대체하는 방식이 필요하다.

그래서 의존성 제거, 원본 섹션 구조의 대폭 수정, 벤더 유닛 자체가 목적에 맞지 않는 수준의 재설계가 필요하면 systemctl edit --full 쪽이 맞다. 반대로 Environment=, Restart=, LimitNOFILE=, ExecStart 재정의 같은 국소 수정은 drop-in이 일반적으로 더 관리하기 쉽다.

 

 

--runtime은 언제 유용할까?

systemctl edit --runtime는 변경을 /run 아래에 기록하므로 다음 부팅에서 사라진다. 일시적인 장애 대응, 특정 배포 직후의 임시 제한 완화, 재부팅 전까지만 필요한 테스트성 조정에 맞는다.

다만 공식 문서는 /etc 아래 유닛이 이미 우선권을 가지는 상황에서는 그 유닛을 임시 편집할 수 없다고 설명한다. 즉, 영구 override가 이미 있는 유닛을 runtime만으로 덮어쓰는 흐름은 기대한 대로 동작하지 않을 수 있다.

revert는 무엇을 되돌릴까?

systemctl revert unit.service는 지정한 유닛의 drop-in 설정과, 벤더 버전을 덮고 있는 사용자 정의 메인 유닛 파일을 제거해 원래 벤더 버전으로 되돌리는 명령이다. 공식 문서는 이 명령이 systemctl edit, systemctl set-property, systemctl mask로 만든 변경을 되돌리는 데 쓸 수 있다고 설명한다.

운영에서는 설정 정리가 꼬였을 때 수동으로 .d/ 디렉터리를 지우기보다, 먼저 systemctl cat로 현재 조합을 확인하고 그다음 revert를 고려하는 편이 안전하다.

운영에서 무난한 선택 기준

상황	무난한 선택	이유
벤더 유닛의 일부 값만 조정	기본 systemctl edit	업데이트 반영을 유지하면서 변경 범위를 최소화할 수 있음
설정을 목적별로 분리 관리	--drop-in=name.conf	리소스 제한, 환경변수, 하드닝을 파일별로 나누기 쉬움
재부팅 전까지만 필요한 임시 조정	--runtime	다음 부팅에서 자동 정리됨
의존성 제거·대규모 구조 변경	--full	drop-in으로는 제거할 수 없는 항목이 있기 때문
현재 적용 조합 점검	systemctl cat	fragment와 drop-in을 한 번에 볼 수 있음

자주 헷갈리는 질문

Q. drop-in을 만들면 매번 직접 daemon-reload를 해야 할까?

systemctl edit로 저장했다면 공식 문서 기준 자동으로 reload가 수행된다. 직접 파일을 수정했을 때는 별도로 daemon-reload가 필요할 수 있다.

Q. override.conf 하나만 써야 할까?

그럴 필요는 없다. 공식 문서에 따르면 --drop-in=NAME으로 파일명을 지정할 수 있고, 여러 drop-in 파일은 사전식 순서로 함께 적용된다.

Q. drop-in만으로 모든 값을 지우거나 의존성을 제거할 수 있을까?

항상 그렇지는 않다. 공식 문서는 dependency 계열은 drop-in에서 빈 목록으로 초기화할 수 없다고 설명한다. 그런 경우는 메인 유닛을 대체하는 쪽을 검토해야 한다.

정리

systemctl edit의 기본 철학은 벤더 유닛 파일을 직접 건드리지 않고 필요한 변경만 분리하는 것이다. 그래서 대부분의 운영 변경은 drop-in으로 시작하는 편이 맞고, 구조적 재정의가 필요할 때만 --full로 올라가는 방식이 관리상 안전하다.

2026년 7월 5일 기준 systemd 261.1 공식 문서만 놓고 보면, 무난한 기본값은 "부분 수정은 drop-in, 임시는 --runtime, 큰 구조 변경만 --full, 문제 분석 전에는 systemctl cat, 원복은 revert"라고 정리할 수 있다.

참고 자료

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