Knowledgebase

적용 환경과 지원 상태

1. 정확한 서비스명 확인

패키지명, 실행 파일명과 systemd 서비스명이 항상 같지는 않습니다. 먼저 설치된 서비스 유닛 목록에서 정확한 이름을 확인합니다.

systemctl list-unit-files --type=service
systemctl list-units --type=service --all

목록이 길다면 서비스 또는 제품 이름 일부로 검색합니다. 아래의 http는 실제 검색어로 변경합니다.

systemctl list-unit-files --type=service | grep -i http
rpm -qa | grep -i http

Unit name.service not found가 표시된다면 서비스명 오타, 패키지 미설치 또는 유닛 파일 누락 가능성이 있습니다. 패키지가 설치되어 있는지와 패키지가 제공하는 서비스 파일을 확인합니다.

rpm -q PACKAGE_NAME
rpm -ql PACKAGE_NAME | grep '/systemd/system/.*\.service$'

2. 서비스 상태와 실패 결과 확인

systemctl status는 유닛의 로드 상태, 실행 상태, 종료 코드, 메인 PID와 최근 로그를 함께 보여줍니다. 먼저 줄이 잘리지 않도록 전체 상태를 확인합니다.

sudo systemctl status name.service -l --no-pager
sudo systemctl is-active name.service
sudo systemctl is-enabled name.service

출력에서 특히 Loaded, Active, Result, Process, status= 값을 확인합니다. status=1/FAILURE처럼 일반적인 종료 코드만 보인다면 서비스 로그나 애플리케이션 자체 로그를 추가로 확인해야 합니다.

systemd가 보관한 주요 속성을 따로 조회하면 상태 출력이 복잡할 때 유용합니다.

sudo systemctl show name.service \
  -p LoadState \
  -p ActiveState \
  -p SubState \
  -p Result \
  -p FragmentPath \
  -p ExecMainCode \
  -p ExecMainStatus

서버 전체에서 실패한 유닛을 확인하려면 다음 명령을 실행합니다. 대상 서비스의 선행 서비스나 마운트 유닛도 함께 실패했다면 의존성 문제일 수 있습니다.

sudo systemctl --failed

3. 서비스별 저널 로그 확인

서비스 시작 실패 직후 현재 부팅 세션의 로그를 확인합니다. -u는 특정 유닛만, -b는 현재 부팅에서 기록된 메시지만 표시합니다.

sudo journalctl -u name.service -b -n 100 --no-pager

문제를 재현하면서 새 로그를 실시간으로 확인하려면 터미널 하나에서 다음 명령을 실행하고, 다른 터미널에서 서비스를 시작합니다.

sudo journalctl -u name.service -f

다른 터미널에서 서비스를 시작합니다.

sudo systemctl start name.service

서비스 로그만으로 원인이 보이지 않으면 같은 시각의 시스템 전체 오류를 확인합니다.

sudo journalctl -b -p err --no-pager
sudo journalctl -xe --no-pager

애플리케이션이 별도 로그 파일을 사용하는 경우에는 해당 파일도 함께 확인합니다. 예를 들어 Apache는 /var/log/httpd/, MariaDB는 설정에 따라 /var/log/mariadb/ 또는 데이터 디렉터리의 오류 로그를 사용할 수 있습니다. 정확한 경로는 서비스 설정과 유닛의 ExecStart 옵션을 기준으로 확인하십시오.

4. 유닛 파일과 override 확인

systemd는 여러 경로의 유닛 파일과 drop-in 설정을 합쳐 최종 구성을 만듭니다. /etc/systemd/system/의 관리자 설정은 /usr/lib/systemd/system/의 패키지 제공 파일보다 우선할 수 있으므로, 실제로 어떤 파일이 적용되는지 확인해야 합니다.

sudo systemctl cat name.service
sudo systemctl show name.service -p FragmentPath -p DropInPaths

systemctl cat 출력에서 유닛 본문과 name.service.d/*.conf 형식의 override를 확인합니다. 오래된 실행 경로, 잘못된 사용자명, 존재하지 않는 환경 파일 또는 중복된 ExecStart 설정이 포함되어 있지 않은지 점검합니다.

유닛 파일 변경 후 systemd 다시 읽기

유닛 파일이나 drop-in 파일을 새로 만들거나 수정했다면 systemd 관리자 구성을 다시 읽어야 합니다.

sudo systemctl daemon-reload

유닛 파일의 기본 구문과 참조 오류를 검사할 때는 실제 적용 경로를 지정해 다음 명령을 사용할 수 있습니다.

sudo systemd-analyze verify /etc/systemd/system/name.service

유닛이 /usr/lib/systemd/system/에 있다면 해당 경로로 변경합니다. 검사 결과에는 대상 유닛이 직접 원인이 아닌 참조 유닛의 경고가 포함될 수 있으므로, 오류가 가리키는 파일과 지시문을 확인해야 합니다.

5. 원인별 진단 방법

5-1. 서비스가 masked 상태인지 확인

Loaded: masked 또는 Unit name.service is masked가 표시되면 먼저 마스크 상태를 확인합니다.

sudo systemctl is-enabled name.service
ls -l /etc/systemd/system/name.service

관리 정책상 의도적으로 차단한 서비스가 아니라면 마스크를 해제하고 다시 시작합니다.

sudo systemctl unmask name.service
sudo systemctl daemon-reload
sudo systemctl start name.service

5-2. 애플리케이션 설정 문법 오류 확인

서비스가 실행 직후 종료된다면 systemd보다 애플리케이션 설정 문법 오류일 가능성이 큽니다. 서비스별 공식 검사 명령을 먼저 실행합니다.

검사에서 파일명과 줄 번호가 표시되면 해당 설정을 백업한 뒤 문법 오류를 수정하고, 검사 명령이 성공한 후 서비스를 다시 시작합니다.

5-3. ExecStart 실행 파일과 스크립트 확인

status=203/EXEC, No such file or directory, Permission denied가 표시되면 유닛의 실행 명령과 파일 상태를 확인합니다.

sudo systemctl show name.service -p ExecStart
sudo systemctl cat name.service

출력에서 확인한 실제 실행 경로를 아래의 /path/to/executable에 입력합니다.

ls -l /path/to/executable
namei -l /path/to/executable
file /path/to/executable

직접 만든 셸 스크립트라면 실행 권한, 첫 줄의 인터프리터 경로와 문법을 추가로 확인합니다.

head -n 1 /path/to/script.sh
bash -n /path/to/script.sh

유닛의 User=, Group=, WorkingDirectory=, EnvironmentFile=에 지정된 계정과 경로가 실제로 존재하는지도 확인합니다.

getent passwd SERVICE_USER
getent group SERVICE_GROUP
ls -ld /path/to/working-directory
ls -l /path/to/environment-file

5-4. 의존 서비스와 시작 조건 확인

Dependency failed for가 표시되거나 서비스가 네트워크, 마운트, 데이터베이스 같은 다른 유닛에 의존한다면 의존 관계와 실패 유닛을 확인합니다.

sudo systemctl list-dependencies name.service
sudo systemctl show name.service -p Requires -p Wants -p After
sudo systemctl --failed

실패한 선행 유닛의 상태와 로그를 같은 방식으로 확인합니다. Condition... 또는 Assert... 조건이 충족되지 않아 시작이 건너뛰어진 경우에는 systemctl status와 저널에 조건 실패 이유가 기록됩니다.

5-5. 포트 또는 PID 파일 충돌 확인

Address already in use가 표시되면 서비스가 사용할 포트를 다른 프로세스가 점유하고 있는지 확인합니다.

sudo ss -lntup

특정 포트만 확인하려면 다음처럼 필터링합니다. 아래의 8080은 실제 포트로 변경합니다.

sudo ss -lntup | grep ':8080 '

PID 파일 관련 오류가 있다면 실제 프로세스가 남아 있는지 먼저 확인하십시오. 실행 중인 프로세스가 없고 로그에서 오래된 PID 파일임이 확인된 경우에만 해당 서비스의 공식 절차에 따라 PID 파일을 제거합니다. 경로를 추측해 임의로 삭제하지 마십시오.

5-6. 파일 권한과 SELinux 차단 확인

일반 Linux 권한이 먼저 적용되므로 서비스 계정이 설정 파일, 인증서, 데이터 디렉터리와 소켓에 필요한 권한을 갖는지 확인합니다.

namei -l /path/to/resource
ls -ld /path/to/resource
ls -lZ /path/to/resource

SELinux AVC 거부가 기록되었는지 최근 감사 로그를 확인합니다.

getenforce
sudo ausearch -m AVC,USER_AVC -ts recent

파일을 복사하거나 이동한 뒤 SELinux 컨텍스트가 잘못된 것이 원인이라면 해당 경로의 기본 정책이 확실할 때 restorecon으로 기본 컨텍스트를 복원합니다.

sudo restorecon -Rv /path/to/resource

5-7. 디스크, inode, 메모리와 OOM 확인

로그, PID 파일, 소켓 또는 임시 파일을 만들 수 없으면 서비스가 시작되지 않을 수 있습니다. 디스크 용량과 inode, 메모리 상태를 확인합니다.

df -h
df -i
free -m
sudo journalctl -k -b --no-pager | grep -i -E 'out of memory|killed process'

Use% 또는 inode 사용률이 100%라면 불필요한 파일을 즉시 무작정 삭제하지 말고, 어느 디렉터리가 공간이나 파일 수를 소비하는지 확인한 뒤 서비스별 보존 정책에 따라 정리합니다. OOM 기록이 있다면 메모리 누수, 과도한 동시 실행 또는 잘못된 자원 제한을 함께 점검합니다.

5-8. Start request repeated too quickly 해결

서비스가 짧은 시간에 반복해서 실패하면 systemd의 시작 제한에 도달하여 Start request repeated too quickly가 표시될 수 있습니다. 먼저 실제 실패 원인을 수정한 뒤 실패 상태를 초기화합니다.

sudo systemctl reset-failed name.service
sudo systemctl start name.service

reset-failed는 원인을 해결하는 명령이 아니라 누적된 실패 상태와 시작 제한 카운터를 초기화하는 명령입니다. 설정 오류가 남아 있으면 다시 실패합니다.

6. 패키지와 유닛 파일 복구

패키지가 제공한 실행 파일이나 유닛 파일이 변경·손상되었는지 확인하려면 먼저 해당 패키지를 식별하고 RPM 검증을 실행합니다. 아래 경로와 패키지명은 실제 값으로 변경합니다.

rpm -qf /usr/lib/systemd/system/name.service
rpm -V PACKAGE_NAME

검증 결과가 있다고 해서 모두 손상은 아닙니다. 설정 파일은 관리자가 정상적으로 수정했어도 차이가 표시될 수 있으므로, 어떤 파일과 속성이 변경되었는지 확인합니다.

패키지 파일이 실제로 손상되었고 저장소를 사용할 수 있다면 설정과 데이터를 먼저 백업한 후 재설치를 검토합니다.

sudo yum reinstall PACKAGE_NAME

CentOS 7은 지원 종료 후 기본 미러 구성이 동작하지 않을 수 있으므로, 재설치 전에 현재 저장소가 신뢰할 수 있는 CentOS Vault 또는 조직 내부 보관 저장소로 올바르게 구성되어 있는지 확인해야 합니다.

잘못된 사용자 override를 임시 제외

문제가 특정 drop-in 파일을 추가한 직후 시작되었다면 해당 파일을 삭제하지 말고 백업 이름으로 이동한 뒤 적용 여부를 비교합니다. 아래 파일명은 실제 systemctl cat 출력에 맞게 변경합니다.

sudo mv /etc/systemd/system/name.service.d/override.conf \
  /etc/systemd/system/name.service.d/override.conf.disabled
sudo systemctl daemon-reload
sudo systemctl start name.service

서비스가 정상화되면 기존 override의 지시문을 검토해 필요한 내용만 올바르게 다시 작성합니다.

7. 수정 후 정상 작동 확인

원인을 수정한 뒤 systemd 구성을 다시 읽고 서비스를 시작합니다. 부팅 시 자동 시작이 필요한 서비스만 enable을 적용합니다.

sudo systemctl daemon-reload
sudo systemctl reset-failed name.service
sudo systemctl start name.service
sudo systemctl status name.service -l --no-pager
sudo systemctl is-active name.service

is-active 결과가 active인지 확인하고, 시작 직후 다시 종료되는 서비스가 아닌지 잠시 후 한 번 더 확인합니다.

sleep 5
sudo systemctl is-active name.service
sudo journalctl -u name.service -b -n 50 --no-pager

네트워크 서비스는 프로세스 상태뿐 아니라 실제 수신 포트와 로컬 기능까지 확인해야 합니다.

sudo ss -lntup

부팅 시 자동 실행이 필요한 서비스라면 현재 기능 검증을 완료한 후 다음 명령을 실행합니다.

sudo systemctl enable name.service
sudo systemctl is-enabled name.service

8. 자주 발생하는 오류와 확인 방법

9. 원상복구 방법

진단 중 변경한 유닛 또는 애플리케이션 설정이 문제를 해결하지 못했거나 다른 장애를 만들었다면 작업 전에 만든 백업으로 되돌립니다. 백업 파일명은 실제 생성한 이름으로 변경합니다.

sudo cp -a /path/to/config.backup /path/to/config
sudo systemctl daemon-reload
sudo systemctl restart name.service

임시로 제외했던 override를 복원하려면 파일명을 원래대로 되돌리고 systemd 구성을 다시 읽습니다.

sudo mv /etc/systemd/system/name.service.d/override.conf.disabled \
  /etc/systemd/system/name.service.d/override.conf
sudo systemctl daemon-reload
sudo systemctl restart name.service

마스크를 해제했지만 원래 의도적으로 차단된 서비스였다는 사실을 확인했다면 다시 마스크할 수 있습니다.

sudo systemctl stop name.service
sudo systemctl mask name.service

자주 묻는 질문

서비스가 disabled이면 시작할 수 없나요?

아닙니다. disabled는 일반적으로 부팅 시 자동 시작 링크가 없다는 뜻이며 systemctl start를 이용한 현재 세션의 수동 시작은 가능합니다. 수동 시작까지 차단하는 상태는 보통 masked입니다.

systemctl status만으로 원인을 알 수 없을 때는 무엇을 확인해야 하나요?

journalctl -u name.service -b로 서비스 전체 로그를 확인하고, 애플리케이션 자체 오류 로그와 설정 검사 명령을 함께 사용해야 합니다. systemd 상태에는 최종 종료 코드만 표시되고 실제 문법 오류는 애플리케이션 로그에 기록되는 경우가 많습니다.

유닛 파일을 수정했는데 변경 내용이 적용되지 않는 이유는 무엇인가요?

유닛 파일을 수정한 뒤 systemctl daemon-reload를 실행하지 않았거나, 더 높은 우선순위의 /etc/systemd/system/ 파일 또는 drop-in override가 기존 설정을 덮어쓰고 있을 수 있습니다. systemctl cat과 FragmentPath, DropInPaths를 확인하십시오.

SELinux를 끄면 서비스가 시작되는데 영구 비활성화해도 되나요?

권장하지 않습니다. SELinux를 끈 상태에서만 시작된다면 감사 로그의 AVC 거부 내용을 확인하고, 파일 컨텍스트, Boolean, 허용 포트 타입 또는 서비스 정책을 올바르게 수정해야 합니다. 전체 SELinux 비활성화는 보호 범위를 크게 줄입니다.

systemctl reset-failed를 실행하면 문제가 해결되나요?

아닙니다. 이 명령은 실패 상태와 시작 제한 카운터를 초기화할 뿐입니다. 실행 파일 누락, 설정 오류, 권한 문제 같은 근본 원인을 먼저 수정해야 서비스가 정상적으로 시작됩니다.

공식 참고자료

• Red Hat Enterprise Linux 7 System Administrator’s Guide — Managing Services with systemd: 서비스 상태, 시작·중지, 활성화, 마스크, 유닛 파일 및 daemon-reload 절차 확인. 조회일: 2026년 7월 24일.
• Red Hat Enterprise Linux 7 System Administrator’s Guide — Viewing and Managing Log Files: journalctl과 현재 부팅 로그 필터링 방법 확인. 조회일: 2026년 7월 24일.
• Red Hat Enterprise Linux 7 SELinux User’s and Administrator’s Guide — Fixing Problems: 일반 Linux 권한, SELinux 거부 로그와 문제 해결 순서 확인. 조회일: 2026년 7월 24일.
• systemd Manual — systemd-analyze(1): 유닛 파일 검증 명령의 용도 확인. 조회일: 2026년 7월 24일.
• The CentOS Project — CentOS Linux 지원 정보: CentOS Linux 7 지원 종료일 확인. 조회일: 2026년 7월 24일.