1. disable과 mask의 동작 범위
시스템 서비스를 비활성화하는 방법은 부팅 자동 실행만 막는 방식과 시스템 전역에서 실행 자체를 차단하는 방식으로 나뉜다. systemctl disable과 systemctl mask는 기능적으로 비슷해 보이지만 차단 범위가 다르다.
1️⃣ systemctl disable의 동작 범위
disable은 부팅 타깃(예: multi-user.target.wants/)에 등록된 심볼릭 링크만 제거한다. 서비스 정의 파일 자체는 그대로 남아 있기 때문에 사용자가 systemctl start 명령으로 직접 실행하거나, 타이머·소켓·다른 서비스의 Requires=, Wants= 관계에 의해 언제든 구동될 수 있다.
2️⃣ systemctl mask의 동작 범위
mask는 /etc/systemd/system/ 경로에 해당 서비스 이름으로 /dev/null을 가리키는 심볼릭 링크를 강제로 생성한다. systemd는 /etc/ 설정을 /lib/systemd/system/의 패키지 기본 유닛 파일보다 우선적으로 읽기 때문에, 서비스를 빈 파일로 취급하여 수동 실행과 의존성에 의한 실행을 포함한 모든 경로의 구동을 차단한다.
| 구분 | systemctl disable | systemctl mask |
| 부팅 시 자동 실행 | 차단 | 차단 |
| 수동 실행 (systemctl start) | 가능 | 불가능 (Unit is masked 에러) |
| 의존성/소켓에 의한 실행 | 가능 (다른 서비스가 요구 시 실행) | 차단 |
| 내부 구현 방식 | .wants/ 디렉터리의 심볼릭 링크 삭제 | /etc/systemd/system/<unit>을 /dev/null로 연결 |
| 복구 명령어 | systemctl enable <서비스> | systemctl unmask <서비스> |
2. 내부 구현 방식 비교
1️⃣ 유닛 파일 탐색 우선순위와 심볼릭 링크 구조
systemd는 유닛을 로드할 때 여러 경로를 우선순위에 따라 탐색한다. /etc/systemd/system/이 /run/systemd/system/보다는 낮고 /lib/systemd/system/(또는 /usr/lib/systemd/system/)보다는 높은 우선순위를 가진다. mask는 이 우선순위 구조를 이용해 /etc/ 경로에 빈 링크를 심어 원본 유닛 파일을 아예 가려버리는 방식으로 동작한다.

3. 상황별 사용 기준
1️⃣ disable 사용
평소 부팅 리소스는 아끼되 필요 시 수동으로 켜야 하는 도구에 적합하다.
예를 들어 백업 스크립트나 수동 진단 에이전트가 해당한다.
2️⃣ mask 사용
동일 포트나 리소스를 두고 충돌하는 서비스를 영구 비활성화할 때 사용한다.
iptables와 firewalld, sendmail과 postfix의 관계가 대표적이며, 패키지 업데이트 트리거 등으로 원치 않게 재시작되는 것을 원천 차단해야 할 때도 사용한다.
4. Mask된 서비스 확인 및 해제 절차
1️⃣ Mask 상태 확인
전체 mask 서비스 목록은 다음 명령으로 조회한다.
systemctl list-unit-files --state=masked
특정 서비스의 상태는 systemctl status <서비스명> 실행 결과에서 확인한다. Loaded: masked (Reason: Unit <서비스명> is masked.) 문구가 출력되거나, 유닛 파일 경로가 /dev/null로 표기된다.
2️⃣ 안전한 Unmask 절차
🔵 1단계: unmask 실행
sudo systemctl unmask <서비스명>
정상 처리되면 /etc/systemd/system/<서비스명>에 연결되어 있던 /dev/null 심볼릭 링크가 삭제된다.
🔵 2단계: 명령어 실패 시 수동 해제
런타임 마스크(/run/systemd/system/)나 권한 문제로 명령어가 동작하지 않는 경우, 링크를 수동으로 제거하고 데몬을 재로드한다.
sudo rm /etc/systemd/system/<서비스명>
sudo rm /run/systemd/system/<서비스명> 2>/dev/null
sudo systemctl daemon-reload
🔵 3단계: 서비스 등록 및 기동
unmask는 실행 차단을 해제하는 동작일 뿐 서비스를 활성화하지는 않는다. 필요에 따라 별도로 활성화하고 시작한다.
sudo systemctl enable --now <서비스명>
5. 주의점 및 발생 가능한 문제
1️⃣ 리소스/포트 충돌
iptables와 firewalld, systemd-resolved와 타 DNS 서버처럼 동일한 포트나 기능을 제어하는 서비스를 대체하기 위해 mask해 둔 경우가 많다. 대체 서비스가 구동 중인 상태에서 unmask 후 실행하면 포트 바인딩 충돌이나 네트워크 단절이 발생한다.
2️⃣ 의존성에 의한 즉각 실행
특정 백그라운드 작업이나 다른 서비스의 설정에 Requires=<해당서비스>가 걸려 있는 경우, unmask 즉시 백그라운드에서 의도치 않게 자동 실행될 수 있다. systemctl list-dependencies --reverse <서비스명> 명령으로 역방향 의존성을 먼저 확인하는 절차가 필요하다.
3️⃣ 패키지 유닛 유실
패키지 삭제 후 설정 찌꺼기로 mask 링크만 남아 있는 경우, unmask 시 원본 유닛 파일(/lib/systemd/system/)을 찾지 못해 Unit file does not exist 에러가 발생한다. 서비스가 정상 구동되려면 해당 패키지를 재설치(apt install --reinstall 또는 dnf reinstall)해야 한다.
'Journey to Security > Linux OS' 카테고리의 다른 글
| UEFI 펌웨어 구조와 부팅 원리 (0) | 2026.08.08 |
|---|---|
| Linux CPU 과점유 대응: top, /proc, strace로 위장 프로세스 추적하기 (0) | 2026.07.21 |
| 리눅스 싱글모드 - GRUB2 보안 설정과 다계층 방어의 중요성 (0) | 2026.06.25 |
| 리눅스 rescue mode에서 chroot /sysroot 동작 원리 (0) | 2026.06.23 |
| awk - 필드 단위 텍스트 처리 도구 (0) | 2026.06.18 |