systemd 203/EXEC 해결: 실행 경로·권한·shebang·noexec 점검 순서

status=203/EXEC는 systemd가 지정한 프로그램을 실제로 실행하는 단계에서 실패했다는 단서입니다. 애플리케이션 설정을 먼저 바꾸거나 재시작을 반복하기보다 journal의 오류 문구를 읽고 실행 경로, 접근 권한, 스크립트 인터프리터와 마운트 조건을 확인하세요. 파일이 존재하는 것만으로 실행 가능하다고 판단할 수 없습니다.

자료 확인 기준일은 2026년 10월 13일입니다. 아래 예시는 공식 문서를 바탕으로 작성한 설계·점검 예이며, 이 글에서 실제 계정이나 서버에 실행한 시험 결과는 아닙니다.

원인: 프로그램이 시작되기 전의 실패입니다

systemd 매뉴얼은 203/EXIT_EXEC를 실제 프로세스 실행, 구체적으로 execve 호출의 실패로 설명합니다. 누락되거나 접근할 수 없는 실행 파일이 대표적인 확인 지점입니다. 203이라는 숫자만으로 모든 환경의 단일 원인을 확정할 수는 없습니다.

Linux의 실행 오류에는 파일·상위 경로 접근이나 실행 권한 문제, noexec 마운트, 없는 인터프리터, 인식하지 못하는 실행 형식 등이 포함될 수 있습니다. 따라서 같은 서비스 이름과 시각의 실제 로그 문구를 먼저 모읍니다.

해결 절차 1: 로그와 실제 unit 설정을 확인합니다

아래의 myapp.service는 예시 이름입니다. 실제 서비스 이름으로 바꾸고 필요한 조회 권한으로 실행하세요. journal에는 비밀 값이나 업무 데이터가 들어갈 수 있으므로 외부 공유 전 해당 내용을 지웁니다. 이 명령은 서비스를 재시작하지 않습니다.

systemctl status myapp.service --no-pager
journalctl -u myapp.service -b -n 50 --no-pager
systemctl cat myapp.service

ExecStart의 첫 실행 파일, User·Group, WorkingDirectory와 추가 설정을 확인합니다. 파일에 쓴 내용과 systemd가 읽고 있는 설정이 다른지, 배포 후 경로가 바뀌었는지도 대조하세요. ExecStart를 로그인 셸에서 그대로 해석하는 명령줄로 생각하지 말고 매뉴얼의 명령 파싱 규칙을 확인해야 합니다.

로그·설정의 단서	우선 확인	서둘러 하지 않을 변경
No such file or directory	실행 파일과 shebang 인터프리터의 실제 경로	추측한 경로로 파일 이동
Permission denied	파일·상위 디렉터리·마운트·서비스 계정 접근	chmod 777·보안 정책 해제
Exec format error	형식·아키텍처·스크립트 첫 줄	재시작만 반복
unit 파일을 수정했음	로드된 설정과 변경 위치	설정 반영 확인 없이 재시작

해결 절차 2: 파일·상위 경로·서비스 계정을 대조합니다

다음은 /opt/myapp/run.sh가 실제 ExecStart 대상인 경우의 조회 예입니다. 경로를 자신의 환경에 맞게 바꾸고, 사용 중인 배포판에서 file·findmnt 같은 조회 도구가 제공되는지 확인하세요.

ls -l /opt/myapp/run.sh
file /opt/myapp/run.sh
head -n 1 /opt/myapp/run.sh
findmnt -T /opt/myapp/run.sh -o TARGET,FSTYPE,OPTIONS

실행 파일의 권한 외에 /opt와 /opt/myapp 등 상위 디렉터리를 서비스 계정이 탐색할 수 있는지도 확인합니다. 관리자 셸에서 파일을 읽을 수 있다는 사실을 서비스 계정의 실행 가능 증거로 대신하지 않습니다. 서비스의 파일시스템 격리 설정이 있다면 그 내부에서 보이는 경로도 검토합니다.

권한 부족이 확인됐다면 파일 소유·그룹·필요한 실행 권한을 해당 계정의 요구에 맞게 교정합니다. 모두에게 쓰기·실행 권한을 주거나 서비스 사용자를 root로 바꾸는 방식은 원인 해결로 삼지 않습니다. 정책에 의해 차단됐다면 정책 담당자와 허용된 배포 경로를 정해야 합니다.

해결 절차 3: shebang과 실행 형식을 확인합니다

직접 실행하는 스크립트는 첫 줄의 인터프리터와 그 경로가 실제로 존재하고 실행 가능한지 확인합니다. 예를 들어 #!/bin/bash를 썼다면 그 서버에 /bin/bash가 있는지를 대조해야 합니다. 배포 과정의 줄 끝 형식도 확인하되 원본을 보존하고 검토한 파일만 수정하세요.

인터프리터를 ExecStart에 명시하는 설계라면 그 인터프리터와 스크립트 경로를 각각 확인합니다. 특정 서버에 없는 도구의 경로를 예제에서 그대로 복사하면 원인이 반복됩니다. 바이너리 형식이나 CPU 아키텍처가 맞지 않는 단서는 별도로 조사하며 모든 실행 실패를 shebang 문제라고 가정하지 않습니다.

셸 연산자나 리다이렉션이 필요한 경우에는 systemd 버전의 명령 규칙을 확인하고 필요한 셸을 명시적으로 선택하는 방식 등을 검토합니다. 단순 실행에 불필요한 셸을 추가해 오류를 가리는 것은 해결 여부를 확인하는 방법이 아닙니다.

해결 절차 4: noexec와 격리 조건을 확인합니다

findmnt의 실제 옵션에 noexec가 보인다면 그 위치가 실행을 제한하려는 저장소인지 확인합니다. 서버 정책을 모르고 remount로 제한을 해제하지 않습니다. 승인된 실행 위치에 검증된 배포 파일을 놓는 방법과 원래 경로를 복원할 기준을 먼저 정하세요.

파일이 호스트에서 보이더라도 unit의 RootDirectory 등 격리 설정에서는 보이지 않을 수 있습니다. 로그와 실제 unit에 나온 조건만 조사하고, 보안 기능을 하나씩 꺼보는 방식으로 원인을 추측하지 않습니다.

확인 방법: 설정 반영·프로세스·앱 응답을 나눕니다

unit 설정을 변경했다면 systemctl daemon-reload로 systemd 설정을 다시 읽는 단계와 서비스 재시작을 구분합니다. daemon-reload만으로 해당 애플리케이션이 재시작되는 것은 아닙니다. 아래 변경 적용 명령은 운영 중단 가능성이 있으므로 원인 교정·변경 승인·원본 보존·작업 시간 확보 후에만 사용하세요.

sudo systemctl daemon-reload
sudo systemctl restart myapp.service
systemctl status myapp.service --no-pager
journalctl -u myapp.service -b -n 50 --no-pager

새 실행 시각에 203/EXEC가 사라졌는지, 의도한 프로세스가 유지되는지 확인한 뒤 애플리케이션의 실제 기능·상태 응답을 검증합니다. 실행 단계가 통과한 후 나타난 앱 오류는 다음 실패 단계로 따로 기록하세요. 시작 요청이 수락된 것만으로 업무 기능까지 정상이라고 판단하지 않습니다.

이 글은 실제 서비스를 재시작하거나 특정 배포판에서 오류를 재현하지 않았습니다. 배포판의 systemd 버전과 제공되는 매뉴얼을 함께 대조하고, 변경 전 unit·실행 파일·권한을 보존해 복원 가능하게 유지하세요.

FAQ

chmod +x만 하면 해결되나요? 실행 권한이 실제 원인일 때 필요한 범위의 교정이 도움이 될 수 있습니다. 경로·인터프리터·마운트 조건 등 다른 실패도 구분해야 합니다.

파일이 있는데 왜 없다고 하나요? 스크립트의 인터프리터나 격리 환경에서 보는 경로가 없는 경우도 확인해야 합니다. journal과 unit의 조건을 대조하세요.

daemon-reload가 서비스를 재시작하나요? unit 설정을 다시 읽는 단계입니다. 실제 서비스 재시작과 이후 앱 기능 확인은 별도입니다.

공식 출처와 관련 글

• systemd 공식 매뉴얼의 203/EXIT_EXEC 정의
• Linux 실행 오류·인터프리터·noexec 조건
• systemd 서비스 실행 명령 규칙
• unit 조회·daemon-reload·restart 구분

함께 읽기: 컨테이너의 exec format error와 CPU 아키텍처 점검

직접 생성한 개념 이미지입니다. 실행 경로·파일 접근·인터프리터를 점검하는 순서이며 실제 오류 화면은 아닙니다.