재부팅하면 게임 서버가 안 켜질 때: systemd 오류 읽는 법

1. 실행 중인지와 부팅 등록 여부는 별개

active는 지금 실행 상태, enabled는 부팅 시 연결된 대상에서 시작하도록 등록됐는지를 나타냅니다. 수동 start만 해 둔 서비스는 재부팅 때 자동 시작하지 않을 수 있습니다. disabled를 발견해도 바로 enable하기 전에 그 서비스가 실제 운영 월드를 가리키는지 확인하세요.

아래 minecraft.service는 예시입니다. static은 다른 유닛이 의존성으로 시작하는 구조일 수 있고 masked는 시작이 차단된 상태입니다. 왜 차단됐는지 확인하지 않고 무조건 해제하지 않습니다.

systemctl is-active minecraft.service
systemctl is-enabled minecraft.service
systemctl status minecraft.service --no-pager -l

2. 이번 부팅의 첫 실패 메시지부터 읽기

status 마지막 줄이 재시작 제한만 보여 주면 그 앞의 진짜 오류가 빠질 수 있습니다. journalctl -b로 이번 부팅 기록을 읽고 첫 실패 시각을 찾습니다. 이전 부팅 로그는 저장돼 있는 경우에만 -b -1로 확인할 수 있습니다.

203/EXEC는 실행 단계의 문제, 200/CHDIR는 작업 디렉터리 이동, 217/USER는 사용자 자격 설정 문제를 좁히는 단서입니다. 이 숫자는 게임 월드가 손상됐다는 뜻이 아닙니다. 반면 실행 뒤 게임이 출력한 모드 오류는 게임 초기화 단계로 봅니다.

journalctl -u minecraft.service -b -n 150 --no-pager
systemctl show minecraft.service -p Result -p ExecMainStatus -p NRestarts

3. ExecStart의 실행 파일과 WorkingDirectory를 확인

unit에 적힌 경로가 업데이트 뒤에도 존재하는지 확인합니다. Java는 내가 터미널에서 쓰는 java와 서비스가 실행하는 절대 경로의 버전이 다를 수 있습니다. Palworld 실행 스크립트도 실행 권한, 첫 줄의 인터프리터, Linux 줄바꿈을 확인해야 합니다.

WorkingDirectory가 틀리면 상대 경로의 설정·모드·월드가 다른 곳에서 읽힐 수 있습니다. 잘못된 경로에서 새 월드가 만들어지는 경우도 있으므로 빈 월드를 보고 저장본을 옮겨 덮기 전에 실제 작업 경로를 확인합니다. 아래 출력에 암호가 포함돼 있다면 공유 전 가립니다.

systemctl cat minecraft.service
systemctl show minecraft.service -p User -p Group -p WorkingDirectory -p ExecStart
ls -ld /srv/minecraft /srv/minecraft/data
ls -l /srv/minecraft/server.jar
/usr/bin/java -version

4. 로그인 셸의 환경을 당연하게 기대하지 않기

서비스는 보통 사용자의 .bashrc를 읽어 PATH나 별칭을 준비하지 않습니다. 터미널에서 설치한 버전 관리자의 java나 상대 경로 스크립트에 의존하면 부팅 후 실패할 수 있습니다. 실행 파일은 확인한 경로로 적고 필요한 환경만 서비스에 명시합니다.

ExecStart는 일반 셸 명령줄과 다릅니다. 파이프, > 리디렉션, &&를 그대로 붙여도 셸처럼 처리되지 않습니다. 복잡한 시작 절차라면 따로 검토한 스크립트를 사용하고 마지막 게임 프로세스의 신호·종료 전달을 확인하세요.

root로만 실행해서 권한 문제를 숨기지 마세요. 서비스 사용자에게 저장 폴더의 필요한 읽기·쓰기 권한이 있는지 확인하고 상위 폴더의 접근 권한도 봅니다. /srv 전체를 chmod 777로 바꾸면 다른 서비스까지 노출됩니다.

5. 외장 디스크가 준비되기 전에 시작하는 문제

월드가 별도 디스크에 있으면 부팅 시 마운트 실패와 서비스 시작 순서를 함께 확인합니다. 경로만 존재해도 안심할 수 없습니다. findmnt에서 기대한 파일시스템이 해당 경로를 담당하는지 확인하고 마운트 실패부터 해결하세요.

RequiresMountsFor=/srv/minecraft/data는 해당 경로 접근에 필요한 마운트 의존성을 표현하는 방법입니다. 하지만 디스크가 원래부터 마운트 유닛이나 fstab에 제대로 등록돼 있어야 합니다. 오타 난 빈 디렉터리에 이 옵션을 넣는 것만으로 디스크 연결이 보장되지는 않습니다.

네트워크가 필요한 시작 작업은 의존성과 실제 실패 처리를 함께 설계합니다. 부팅 때 자동 업데이트까지 묶으면 인터넷·배포 서버 장애가 게임 실행 실패로 이어질 수 있으므로 업데이트와 평상시 기동을 따로 점검할 수 있게 구성하는 편이 원인 파악에 도움이 됩니다.

findmnt -T /srv/minecraft/data
systemctl --failed --no-pager

6. 원인을 고친 뒤 설정 재읽기와 시작

unit 파일을 고쳤으면 daemon-reload로 설정을 다시 읽힙니다. reset-failed는 실패 상태와 시작 제한 카운터를 초기화하는 절차이며 잘못된 실행 경로를 고쳐 주는 명령은 아닙니다. 이미 정상 실행 중이면 아래 start는 재시작을 대신하지 않습니다. 실행 중 설정 적용은 저장 후 별도 점검 시간에 진행합니다.

Restart=on-failure와 적당한 재시작 간격은 일시 오류를 처리할 수 있지만 잘못된 경로·권한을 영원히 재시도하면 로그만 늘어납니다. 짧은 간격의 무한 반복보다 첫 실패를 보존하고 원인을 수정하는 것이 우선입니다.

sudo systemctl daemon-reload
sudo systemctl reset-failed minecraft.service
sudo systemctl start minecraft.service
systemctl status minecraft.service --no-pager -l

7. 마지막 검증은 계획된 재부팅 후 실제 접속

수동 시작과 저장·정상 종료가 검증된 서비스만 부팅 자동 시작으로 등록합니다. 그 뒤 이용자에게 점검 시간을 알리고 재부팅 후 마운트, 프로세스, 월드 로딩, 외부 접속 순서로 확인합니다. 이 글의 예제 명령에는 운영 호스트를 바로 재부팅하는 명령을 넣지 않았습니다.

서버가 켜져도 새 월드나 다른 저장 경로를 열었다면 성공이 아닙니다. 평소 건축물·플레이어 상태를 확인하고 작은 변경을 저장한 뒤 다시 접속해 남는지 봅니다. 이번 부팅 로그와 최종 unit 설정을 기록해 다음 업데이트 때 비교할 기준으로 둡니다.

검증 범위와 공식 참고자료

공식 문서와 명령 옵션을 확인해 작성한 Linux 운영 가이드입니다. 이 글의 경로·서비스명·주소와 진단 상황은 설명용이며 실제 SameOS 게임 서버 장애 기록이나 성능 측정값이 아닙니다. 운영 서버에서 장애를 유발하거나 저장 데이터를 변경하는 실험은 하지 않았습니다. 게임 빌드와 설치 방식에 따라 설정·저장 위치가 다르므로 실제 환경을 확인한 뒤 적용하세요.

• systemctl 실행·등록·재읽기
• systemd 실행 환경과 종료 코드
• systemd 서비스와 재시작 동작
• systemd 마운트 의존성

SameOS 작성·번역·검수 원칙 보기