리눅스 서버 서비스가 안 뜰 때 systemctl status와 journalctl로 원인 좁히는 과정

서비스가 안 뜰 때 바로 재기동하지 않고, systemctl status와 journalctl로 원인을 먼저 확인하는 리눅스 서버 장애 대응 흐름

리눅스 서버를 운영하다 보면 서비스가 안 뜨는 상황을 만날 때가 있습니다.

처음에는 단순하게 보입니다.

서비스가 안 뜬다.
프로세스가 죽은 것 같다.
restart 하면 되지 않을까?

저도 처음에는 이렇게 생각했습니다.
그런데 운영 서버에서는 서비스가 안 뜬다고 바로 restart부터 하는 것이 항상 좋은 선택은 아닙니다.

서비스가 실패한 이유를 확인하지 않고 재기동하면, 잠깐 살아나는 것처럼 보여도 같은 문제가 다시 반복될 수 있습니다.
또는 실패 원인이 로그에 남아 있었는데 재기동 과정에서 중요한 단서를 놓칠 수도 있습니다.

이번 글에서는 리눅스 서버에서 서비스가 안 뜰 때, systemctl status와 journalctl을 이용해서 원인을 좁혀가는 실제 점검 흐름을 정리해보겠습니다.

핵심은 단순합니다.

서비스가 안 뜰 때는 바로 restart 하지 말고, 먼저 상태와 로그를 확인해야 합니다.

운영 서버에서는 항상 확인 → 판단 → 조치 → 재확인 순서가 먼저입니다.

---

1. 먼저 “서비스가 안 뜬다”는 말을 나눠서 봅니다

운영 중에 “서비스가 안 떠요”라는 말을 들으면, 바로 명령어부터 치기 전에 상황을 나눠서 봐야 합니다.

서비스가 안 뜬다는 말 안에는 여러 경우가 섞여 있을 수 있습니다.

• 프로세스가 아예 없음
• systemd 서비스가 failed 상태임
• 프로세스는 있는데 포트가 안 열림
• 포트는 열렸는데 응답이 없음
• 재기동 직후 바로 죽음
• 서버 재부팅 후 자동으로 안 올라옴

이 상황들은 모두 비슷해 보이지만 확인 순서가 조금씩 다릅니다.

그래서 먼저 이렇게 생각합니다.

서비스가 안 뜬다.
그러면 먼저 현재 서비스 상태부터 확인한다.

이때 가장 먼저 볼 명령어가 systemctl status입니다.

---

2. systemctl status로 현재 상태를 확인합니다

서비스가 안 뜰 때 가장 먼저 확인할 명령어는 보통 아래와 같습니다.

systemctl status 서비스명 --no-pager

예를 들어 nginx라면 이렇게 볼 수 있습니다.

systemctl status nginx --no-pager

여기서 중요한 것은 단순히 active인지 failed인지만 보는 것이 아닙니다.

아래 항목을 같이 봐야 합니다.

• Loaded 상태
• Active 상태
• Main PID 존재 여부
• 최근 종료 코드
• 최근 로그 일부
• 서비스가 언제부터 실패했는지
• 어떤 설정 파일을 바라보는지

예를 들어 Active: failed가 보이면 서비스가 시작에 실패한 것입니다.
Active: inactive라면 현재 실행 중이 아닌 상태일 수 있습니다.
Active: activating 상태가 오래 지속된다면 시작 중 멈춰 있는 상황일 수도 있습니다.

초보 운영자라면 이 문장만 기억해도 좋습니다.

서비스가 안 뜰 때는 restart보다 status가 먼저입니다.

systemctl status로 서비스 상태를 먼저 확인하는 방법은 아래 글에서 정리했습니다.

https://opsnote.tistory.com/27

리눅스 서버 서비스가 안 뜰 때 재기동부터 하지 말고 systemctl status 먼저 확인하는 법

 

---

3. status 결과만 보고 단정하지 않습니다

systemctl status를 보면 어느 정도 힌트가 나옵니다.

하지만 status 결과만으로 원인을 모두 알 수는 없습니다.

예를 들어 이런 식입니다.

Active: failed
Main PID: exited
code=exited
status=1/FAILURE

이 결과만 보고는 정확한 원인을 알기 어렵습니다.

설정 파일 오류인지, 포트 충돌인지, 권한 문제인지, 디렉터리가 없는지, 환경 변수가 빠졌는지까지는 추가 로그를 봐야 알 수 있습니다.

그래서 status는 시작점이고, 다음은 로그 확인입니다.

흐름은 이렇게 잡습니다.

systemctl status로 현재 상태 확인
→ failed 또는 exited 확인
→ journalctl로 자세한 로그 확인

---

4. journalctl로 실패 원인을 확인합니다

systemd 서비스의 최근 로그를 확인할 때는 journalctl을 사용합니다.

기본 형태는 아래와 같습니다.

journalctl -u 서비스명 -n 100 --no-pager

nginx라면 이렇게 확인할 수 있습니다.

journalctl -u nginx -n 100 --no-pager

여기서 -u는 특정 서비스 로그를 보는 옵션이고, -n 100은 최근 100줄을 보겠다는 뜻입니다.

서비스가 안 뜨는 상황에서는 최근 로그가 중요합니다.

특히 아래 메시지를 찾습니다.

• permission denied
• address already in use
• no such file or directory
• failed to start
• configuration error
• cannot bind
• timeout
• dependency failed

예를 들어 address already in use가 보이면 포트 충돌을 의심할 수 있습니다.
permission denied가 보이면 권한 문제를 의심할 수 있습니다.
no such file or directory가 보이면 경로나 파일 누락을 확인해야 합니다.

서비스 실패 원인을 journalctl로 확인하는 방법은 아래 글에서 이어서 볼 수 있습니다.

https://opsnote.tistory.com/33

리눅스 서버 systemctl status만 보지 말고 journalctl로 서비스 로그 확인하는 법

 

---

5. 실패한 서비스가 여러 개인지도 확인합니다

서비스 하나만 실패한 것처럼 보여도, 실제로는 여러 서비스가 함께 실패했을 수 있습니다.

이럴 때는 systemctl --failed를 사용합니다.

systemctl --failed

이 명령어는 현재 실패 상태인 systemd unit을 한 번에 보여줍니다.

운영 서버에서는 서비스 하나만 보고 판단하면 놓치는 경우가 있습니다.

예를 들어 애플리케이션 서비스가 failed 상태인데, 실제 원인은 그 앞단의 데이터베이스, 마운트, 네트워크 관련 서비스일 수도 있습니다.

그래서 서비스가 이상할 때는 이렇게 봅니다.

문제가 된 서비스 하나만 보지 않는다.
실패한 서비스 목록도 함께 확인한다.

실패한 서비스 목록을 확인하는 방법은 아래 글에서 정리했습니다.

https://opsnote.tistory.com/32

리눅스 서버에서 실패한 서비스 한 번에 확인하는 systemctl --failed 사용법

 

---

6. 포트가 열렸는지도 같이 봅니다

서비스가 active로 보인다고 해서 실제로 접속 가능한 상태라고 단정하면 안 됩니다.

프로세스는 떠 있는데 포트가 열리지 않았을 수도 있습니다.
또는 포트는 열렸지만 다른 프로세스가 잡고 있을 수도 있습니다.

포트 확인은 이렇게 할 수 있습니다.

ss -lntp

특정 포트만 보고 싶다면 이렇게 확인합니다.

ss -lntp | grep ':80'

웹 서비스라면 HTTP 응답도 같이 확인합니다.

curl -I http://localhost

이렇게 보면 상태를 나눌 수 있습니다.

systemctl status는 active
→ 포트도 열림
→ HTTP 응답 확인

systemctl status는 active
→ 포트가 안 열림
→ 설정 또는 서비스 내부 문제 의심

systemctl status는 failed
→ journalctl로 실패 원인 확인

서비스 확인은 하나의 명령어로 끝내기보다, 상태와 포트와 로그를 함께 보는 것이 좋습니다.

---

7. 바로 restart 하지 않는 이유

서비스가 안 뜰 때 가장 쉽게 떠오르는 명령어는 restart입니다.

systemctl restart 서비스명

하지만 운영 서버에서는 이 명령어를 먼저 치기보다, 먼저 확인해야 합니다.

왜냐하면 restart는 원인 확인이 아니라 조치에 가깝기 때문입니다.

원인을 모른 채 restart를 하면 아래 문제가 생길 수 있습니다.

• 실패 원인을 놓칠 수 있음
• 같은 장애가 다시 반복될 수 있음
• 로그 단서가 뒤섞일 수 있음
• 순간적으로 서비스 영향이 생길 수 있음
• 의존 서비스 문제를 감출 수 있음

그래서 restart는 이렇게 생각하는 것이 좋습니다.

restart는 첫 번째 확인 명령어가 아니라,
상태와 로그를 본 뒤 선택하는 조치입니다.

start, stop, restart 차이는 아래 글에서 정리했습니다.

https://opsnote.tistory.com/28

리눅스 서버 systemctl start stop restart 차이와 restart 바로 누르면 안 되는 이유

 

---

8. restart를 했다면 반드시 재확인합니다

상태와 로그를 확인한 뒤 재기동이 필요하다고 판단했다면, 그때 restart를 실행할 수 있습니다.

systemctl restart 서비스명

하지만 여기서 끝내면 안 됩니다.

restart가 성공적으로 끝났다는 것과 서비스가 정상이라는 것은 다릅니다.

재기동 후에는 다시 확인해야 합니다.

systemctl status 서비스명 --no-pager

포트도 봅니다.

ss -lntp | grep ':포트'

최근 로그도 확인합니다.

journalctl -u 서비스명 -n 100 --no-pager

웹 서비스라면 응답도 확인합니다.

curl -I http://localhost

재기동 후 확인할 것은 아래와 같습니다.

• 서비스가 active 상태인지
• Main PID가 정상적으로 존재하는지
• 포트가 열렸는지
• HTTP 응답이 정상인지
• 최근 로그에 에러가 새로 찍히지 않는지
• 일정 시간이 지나도 다시 죽지 않는지

재기동 후 정상 여부를 확인하는 순서는 아래 글에서 이어서 볼 수 있습니다.

https://opsnote.tistory.com/29

리눅스 서버 systemctl restart 후 정상 기동 확인하는 법, 명령어만 치고 끝내지 마세요

 

---

9. 서버 재부팅 후 자동으로 안 뜬다면 enable도 확인합니다

서비스가 수동으로는 뜨는데, 서버 재부팅 후 자동으로 안 뜨는 경우도 있습니다.

이때는 enable 설정을 확인해야 합니다.

현재 서비스가 실행 중인지 보는 명령어와, 재부팅 후 자동 기동 설정을 보는 명령어는 다릅니다.

현재 실행 상태는 이렇게 봅니다.

systemctl is-active 서비스명

자동 기동 설정은 이렇게 봅니다.

systemctl is-enabled 서비스명

서비스를 지금 켜는 것은 start이고, 서버 재부팅 후 자동으로 켜지게 설정하는 것은 enable입니다.

이 둘을 헷갈리면 이런 일이 생길 수 있습니다.

지금은 서비스가 정상으로 보인다.
그런데 서버 재부팅 후 다시 안 뜬다.

이런 경우에는 is-enabled를 함께 확인해야 합니다.

서비스 자동 기동 설정 확인은 아래 글에서 정리했습니다.

https://opsnote.tistory.com/30

리눅스 서버 재기동 후 서비스가 자동으로 안 뜰 때 systemctl enable disable 차이 확인하는 법

 

---

10. 조치 전에는 영향도를 정리합니다

서비스가 안 뜬 원인을 어느 정도 찾았다면 조치를 고민해야 합니다.

하지만 운영 서버에서는 조치 전에 영향도를 먼저 봐야 합니다.

예를 들어 아래 작업은 모두 영향이 있을 수 있습니다.

• restart
• stop
• 설정 파일 수정
• 권한 변경
• 포트 변경
• 프로세스 kill
• 서버 재부팅

그래서 조치 전에는 최소한 아래 내용을 정리하는 것이 좋습니다.

확인된 사실:
서비스 상태, 실패 시간, 로그 메시지

추정 원인:
포트 충돌, 설정 오류, 권한 문제, 파일 누락, 의존 서비스 문제

조치 계획:
설정 수정, 서비스 재기동, 권한 조정, 담당자 확인

영향 범위:
서비스 중단 가능성, 사용자 영향, 재발 가능성

원복 방법:
변경 전 설정 백업, 이전 값 기록, 재기동 전 상태 확인

운영 서버에서는 빨리 조치하는 것보다, 안전하게 확인하고 조치하는 것이 더 중요합니다.

---

11. 보고는 상태와 로그 중심으로 남깁니다

서비스 장애를 확인한 뒤에는 보고도 남겨야 합니다.

보고는 길게 쓰기보다, 확인한 사실과 조치 내용을 나눠서 적는 것이 좋습니다.

예시는 이렇게 정리할 수 있습니다.

[현상]
서비스 접속 불가 및 프로세스 미기동 상태 확인

[확인]
systemctl status 확인 결과 서비스 failed 상태 확인
journalctl 확인 결과 설정 파일 경로 오류 메시지 확인
systemctl --failed 확인 결과 동일 서비스만 failed 상태 확인
포트 listen 상태 없음 확인

[조치]
설정 파일 경로 수정 후 서비스 재기동
재기동 후 systemctl status active 상태 확인
포트 listen 및 HTTP 응답 정상 확인

[결과]
서비스 정상 기동 확인
최근 로그에서 동일 오류 재발 없음

[추가 확인]
재부팅 후 자동 기동 설정 확인 예정

이렇게 정리하면 보는 사람도 상황을 빠르게 이해할 수 있습니다.

“서비스가 안 떠서 재기동했습니다”보다 훨씬 낫습니다.

---

12. 정리하면

리눅스 서버에서 서비스가 안 뜰 때 가장 먼저 할 일은 restart가 아닙니다.

먼저 현재 상태와 로그를 확인해야 합니다.

1. systemctl status로 서비스 상태를 확인합니다.
2. journalctl로 최근 실패 로그를 확인합니다.
3. systemctl --failed로 실패한 서비스 목록을 봅니다.
4. 포트 listen 여부를 확인합니다.
5. HTTP 응답이 필요한 서비스라면 curl로 응답을 봅니다.
6. restart가 필요하면 조치 후 반드시 다시 확인합니다.
7. 재부팅 후 자동으로 안 뜬다면 is-enabled를 확인합니다.
8. 조치 전 영향도와 원복 방법을 정리합니다.

초보 운영자라면 이 문장만 기억해도 좋습니다.

서비스가 안 뜰 때는 restart 전에 systemctl status와 journalctl부터 확인하세요.

서비스 장애 대응도 결국 같습니다.

확인 → 판단 → 조치 → 재확인

서비스 상태 확인을 명령어별로 더 자세히 보고 싶다면 아래 글들을 함께 보면 좋습니다.

https://opsnote.tistory.com/27

리눅스 서버 서비스가 안 뜰 때 재기동부터 하지 말고 systemctl status 먼저 확인하는 법

 

https://opsnote.tistory.com/33

리눅스 서버 systemctl status만 보지 말고 journalctl로 서비스 로그 확인하는 법

 

https://opsnote.tistory.com/32

리눅스 서버에서 실패한 서비스 한 번에 확인하는 systemctl --failed 사용법

 

https://opsnote.tistory.com/28

리눅스 서버 systemctl start stop restart 차이와 restart 바로 누르면 안 되는 이유

 

https://opsnote.tistory.com/29

리눅스 서버 systemctl restart 후 정상 기동 확인하는 법, 명령어만 치고 끝내지 마세요

 

https://opsnote.tistory.com/30

리눅스 서버 재기동 후 서비스가 자동으로 안 뜰 때 systemctl enable disable 차이 확인하는 법

 

리눅스 서버 장애 대응 전체 흐름은 아래 글에서 정리했습니다.

https://opsnote.tistory.com/69

초보 운영자를 위한 리눅스 서버 장애 대응 순서 총정리