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

리눅스 서버에서 서비스가 안 뜰 때 바로 재기동하지 않고 systemctl status로 Active 상태, Main PID, 에러 메시지, journalctl 로그와 포트 상태를 확인하는 방법을 설명하는 대표 이미지

 

리눅스 서버를 운영하다 보면 “서비스가 안 떠요”, “접속이 안 됩니다”, “프로세스가 죽은 것 같습니다” 같은 상황을 만날 수 있습니다.

이럴 때 초보 운영자 입장에서 가장 먼저 떠오르는 조치는 보통 재시작입니다.

systemctl restart 서비스명

 

물론 재시작으로 해결되는 경우도 있습니다. 하지만 실제 운영 서버에서는 바로 재시작부터 하면 원인을 놓칠 수 있습니다.

서비스가 정말 죽은 것인지, 실행 중인데 접속만 안 되는 것인지, 자동 재시작 중인지, 설정 오류로 실패한 것인지 먼저 확인해야 합니다.

그때 가장 기본으로 확인하는 명령어가 systemctl status입니다.

이번 글에서는 리눅스 서버에서 서비스가 안 뜨는 것 같을 때 systemctl status로 무엇을 먼저 확인하면 좋은지 정리합니다.

systemctl status는 언제 볼까?

systemctl status는 systemd로 관리되는 서비스의 현재 상태를 확인하는 명령어입니다.

예를 들어 nginx 상태를 보려면 이렇게 입력합니다.

 

systemctl status nginx

 

sshd 상태를 보려면 이렇게 볼 수 있습니다.

systemctl status sshd

 

서비스 이름은 서버 환경마다 다를 수 있습니다.

예를 들어 Apache는 배포판에 따라 httpd 또는 apache2일 수 있습니다.

 

 

systemctl status httpd
systemctl status apache2

 

서비스가 안 뜬다고 느껴질 때는 먼저 이 명령어로 현재 상태를 보는 것이 좋습니다.

바로 restart 하지 말고 status부터 보는 이유

장애 상황에서 무조건 재시작부터 하면 당장은 살아날 수 있습니다.

하지만 왜 죽었는지 확인할 기회를 놓칠 수 있습니다.

예를 들어 서비스가 실패 상태라면 systemctl status에서 이런 단서가 나올 수 있습니다.

Active: failed
Main PID: 1234
ExecStart failed
permission denied
address already in use

 

이런 정보는 재시작 후 사라지거나 흐려질 수 있습니다.

그래서 서비스가 안 뜬다고 판단되면 보통 아래 순서로 확인하는 것이 좋습니다.

1. systemctl status로 현재 상태 확인
2. Active 상태 확인
3. Main PID 확인
4. 아래쪽 에러 메시지 확인
5. journalctl로 최근 로그 확인
6. 포트 LISTEN 상태 확인
7. 필요할 때 재시작 판단

 

핵심은 재시작이 나쁘다는 뜻이 아닙니다.

재시작 전에 상태를 먼저 확인하고, 필요한 단서를 남기는 것이 중요합니다.

 

서버 전체를 재기동해야 할지 고민되는 상황이라면 아래 체크리스트도 함께 보면 좋습니다.

https://opsnote.tistory.com/19

리눅스 서버 재기동 전 바로 껐다 켜지 말고 확인해야 할 체크리스트

 

가상의 운영 상황 예시

예를 들어 웹 서비스 접속이 안 된다는 문의가 들어왔다고 가정해보겠습니다.

[상황]
- 사용자가 웹페이지 접속 불가 제보
- nginx 또는 애플리케이션 서비스 문제로 의심
- 서비스가 죽었는지, 포트가 안 열린 것인지 확인 필요
- 바로 restart를 하기에는 운영 영향이 있을 수 있음

 

이때 바로 아래 명령어부터 실행하면 조심해야 합니다.

 

systemctl restart nginx

 

먼저 상태를 확인합니다.

 

systemctl status nginx --no-pager

 

여기서 서비스가 active (running)인지, failed인지, inactive인지 확인합니다.

그다음 포트와 로그를 이어서 확인합니다.

 

ss -lntp | grep ':80'
journalctl -u nginx -n 100 --no-pager

 

이렇게 보면 문제를 조금 나눠서 볼 수 있습니다.

서비스가 failed
→ 서비스 기동 실패 가능성

서비스는 active인데 포트가 안 열림
→ 설정, 포트 바인딩, 애플리케이션 기동 문제 가능성

서비스도 active이고 포트도 LISTEN
→ curl, 로그, 앞단 네트워크 확인 필요

 

장애 대응에서는 “서비스 안 됩니다”를 바로 “restart 해야 합니다”로 연결하지 않는 것이 중요합니다.

1단계. systemctl status 기본 사용법

기본 명령어는 아래와 같습니다.

 

systemctl status 서비스명

 

예를 들어 nginx라면 이렇게 확인합니다.

 

systemctl status nginx

 

출력 예시는 대략 이런 형태입니다.

● nginx.service - The nginx HTTP and reverse proxy server
   Loaded: loaded (/usr/lib/systemd/system/nginx.service; enabled)
   Active: active (running) since Tue 2026-05-26 10:20:11 KST
 Main PID: 1234 (nginx)
   Status: "Running"

 

처음 보면 내용이 많아 보일 수 있습니다.

하지만 초보 운영자 기준으로는 우선 아래 항목부터 보면 됩니다.

- Loaded
- Active
- Main PID
- 최근 에러 메시지

 

처음부터 모든 줄을 완벽히 해석하려고 하기보다, 서비스가 실행 중인지 실패했는지부터 보는 것이 좋습니다.

2단계. Active 상태 먼저 보기

systemctl status에서 가장 먼저 볼 부분은 Active입니다.

정상 실행 중일 때는 아래처럼 보입니다.

Active: active (running)

 

이 상태면 서비스는 일단 실행 중입니다.

하지만 여기서 바로 “정상입니다”라고 말하면 안 됩니다.

서비스가 실행 중이어도 포트가 열려 있지 않거나, 애플리케이션 응답이 실패하거나, 뒤쪽 연동이 실패할 수 있습니다.

이 경우에는 다음 단계로 포트, curl, 로그를 봐야 합니다.

 

ss -lntp | grep ':80'
curl -I http://localhost
journalctl -u nginx -n 100 --no-pager

 

포트 확인은 아래 글에서 더 자세히 정리했습니다.

https://opsnote.tistory.com/18

리눅스 서버 접속이 안 될 때 netstat보다 ss로 포트 확인하는 이유

 

3단계. failed 상태일 때 바로 restart 하지 않기

서비스가 실패 상태라면 아래처럼 보일 수 있습니다.

Active: failed

 

이 상태는 서비스 시작에 실패했거나 비정상 종료된 상태입니다.

이때 바로 restart를 누르기보다 아래쪽 에러 메시지를 먼저 봐야 합니다.

자주 볼 수 있는 원인은 이런 것들입니다.

- 설정 파일 오류
- 권한 문제
- 포트 충돌
- 필수 파일 없음
- 환경 변수 누락
- 디스크 용량 부족
- 의존 서비스 미기동

 

예를 들어 아래 메시지가 보이면 포트 충돌 가능성이 있습니다.

address already in use

 

이 경우에는 어떤 프로세스가 포트를 사용 중인지 확인해야 합니다.

 

ss -lntp | grep ':80'

 

아래 메시지가 보이면 권한 문제일 수 있습니다.

permission denied

 

아래 메시지가 보이면 설정 파일 오류를 의심할 수 있습니다.

syntax error
invalid configuration

 

failed 상태에서는 status 출력 아래쪽 메시지를 먼저 남겨두는 것이 좋습니다.

그다음 journalctl로 자세한 로그를 확인합니다.

 

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

 

서비스 로그를 더 자세히 보는 방법은 아래 글에서 이어서 확인할 수 있습니다.

https://opsnote.tistory.com/33

리눅스 서버 서비스 장애 났을 때 journalctl로 systemd 로그 확인하는 법

 

4단계. inactive 상태가 항상 장애는 아닙니다

서비스가 실행 중이 아니면 아래처럼 보일 수 있습니다.

Active: inactive (dead)

 

이 상태는 현재 서비스가 실행 중이 아니라는 뜻입니다.

하지만 이것만 보고 무조건 장애라고 단정하면 안 됩니다.

확인해야 할 것은 아래입니다.

- 원래 상시 실행되는 서비스인지
- 필요할 때만 실행되는 서비스인지
- 서버 재기동 후 자동으로 떠야 하는 서비스인지
- 누군가 의도적으로 중지한 서비스인지
- 배치성 서비스인지

 

예를 들어 웹서버나 애플리케이션 서비스가 inactive라면 문제가 될 수 있습니다.

하지만 특정 일회성 서비스나 타이머로 실행되는 서비스라면 inactive가 정상일 수도 있습니다.

중요한 것은 서비스의 역할을 먼저 확인하는 것입니다.

5단계. activating 상태도 확인하기

가끔 서비스가 아래처럼 보일 수 있습니다.

Active: activating (start)

 

이 상태는 서비스가 시작 중이라는 뜻입니다.

잠깐 보였다가 active (running)으로 바뀌면 괜찮을 수 있습니다.

하지만 오래 activating 상태로 멈춰 있다면 다음을 의심할 수 있습니다.

- 기동 과정에서 외부 연동 대기
- DB 연결 대기
- 설정 로딩 지연
- 의존 서비스 대기
- 서비스 시작 스크립트 문제

 

이때는 상태만 보지 말고 최근 로그를 같이 확인합니다.

 

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

 

필요하면 실시간 로그도 확인합니다.

 

journalctl -u nginx -f

 

애플리케이션 로그 파일을 직접 보는 상황이라면 tail -f로 새 로그가 찍히는지도 확인할 수 있습니다.

https://opsnote.tistory.com/21

리눅스 서버 장애 났을 때 tail -f로 실시간 로그 확인하는 법

 

6단계. Loaded 상태도 같이 보기

Loaded 줄에서는 서비스 파일이 제대로 로드되었는지 볼 수 있습니다.

예를 들어 정상이라면 이런 식입니다.

Loaded: loaded (/usr/lib/systemd/system/nginx.service; enabled)

 

여기서 볼 부분은 두 가지입니다.

loaded 여부
enabled 여부

 

loaded는 서비스 유닛 파일을 systemd가 인식하고 있다는 뜻입니다.

enabled는 서버 재기동 후 자동으로 올라오도록 설정되어 있다는 뜻입니다.

반대로 disabled라면 서버가 재기동된 뒤 자동으로 뜨지 않을 수 있습니다.

Loaded: loaded (...; disabled)

 

이때는 현재 실행 상태와 자동 기동 설정을 구분해야 합니다.

active
→ 지금 실행 중인지

enabled
→ 서버 재기동 후 자동으로 실행될 설정인지

 

서버 재기동 후 서비스가 자동으로 안 뜨는 문제는 아래 글들과 연결해서 보면 좋습니다.

https://opsnote.tistory.com/30

리눅스 서버 재기동 후 서비스 안 뜨는 이유와 systemctl enable disable 차이

 

https://opsnote.tistory.com/31

리눅스 서버 재기동 후 서비스 안 뜬다면 자동 기동 설정 확인하는 법

 

7단계. Main PID 확인하기

서비스가 실행 중이면 보통 Main PID가 보입니다.

Main PID: 1234 (nginx)

 

이건 해당 서비스의 대표 프로세스 PID입니다.

PID가 보인다고 무조건 정상이라는 뜻은 아니지만, 최소한 서비스 프로세스가 떠 있는지는 확인할 수 있습니다.

추가로 프로세스 상태를 보고 싶다면 아래처럼 확인할 수 있습니다.

 

ps -ef | grep nginx

 

포트까지 확인하려면 아래처럼 봅니다.

 

ss -lntp | grep nginx

 

여기서 중요한 것은 systemctl status는 서비스 상태 확인의 시작점이라는 점입니다.

상태를 본 뒤에 프로세스, 포트, 로그로 이어가야 합니다.

8단계. 아래쪽 로그 메시지 확인하기

systemctl status 출력 아래쪽에는 최근 로그가 같이 보이는 경우가 많습니다.

예를 들어 이런 메시지가 있을 수 있습니다.

Failed to start nginx.service
bind() to 0.0.0.0:80 failed
address already in use

 

이런 경우는 서비스 자체 문제라기보다 이미 다른 프로세스가 해당 포트를 사용 중일 가능성이 있습니다.

또는 이런 메시지도 볼 수 있습니다.

permission denied

 

이 경우는 권한 문제일 수 있습니다.

또 이런 메시지는 설정 파일 문제일 수 있습니다.

invalid configuration
syntax error

 

초보 운영자 입장에서는 영어 메시지가 길면 부담스러울 수 있습니다.

하지만 핵심 키워드만 봐도 방향이 잡히는 경우가 많습니다.

failed
denied
syntax error
address already in use
not found
timeout
refused
permission

 

이런 단어가 보이면 바로 넘기지 말고 따로 적어두는 것이 좋습니다.

로그에서 특정 키워드를 찾는 방법은 아래 글들도 함께 보면 흐름이 이어집니다.

https://opsnote.tistory.com/24

리눅스 서버 로그에서 에러 찾을 때 grep만 믿지 말고 앞뒤 흐름까지 확인하는 법

 

https://opsnote.tistory.com/26

리눅스 서버 로그에서 정상 로그가 너무 많을 때 grep -v로 제외하고 확인하는 법

 

9단계. status 출력이 길면 --no-pager 사용하기

가끔 systemctl status를 실행했을 때 화면이 less처럼 열리는 경우가 있습니다.

그럴 때는 q를 눌러 빠져나오면 됩니다.

처음부터 페이지 전환 없이 보고 싶다면 --no-pager 옵션을 붙일 수 있습니다.

 

systemctl status nginx --no-pager

 

운영 중 빠르게 상태를 확인할 때는 이 옵션이 편할 때가 있습니다.

 

systemctl status 서비스명 --no-pager

 

로그를 볼 때 tail, less, grep을 어떻게 나눠 쓰면 좋은지는 아래 글에서 정리했습니다.

https://opsnote.tistory.com/20

리눅스 서버 로그 확인할 때 cat부터 치지 말고 tail과 less로 안전하게 보는 법

 

10단계. 서비스가 failed일 때 확인 순서

서비스 상태가 failed라면 바로 재시작하지 말고 아래를 먼저 봅니다.

1. Active가 failed인지 확인
2. status 아래쪽 에러 메시지 확인
3. 최근 journal 로그 확인
4. 설정 파일 변경 이력 확인
5. 포트 충돌 여부 확인
6. 디스크 용량 문제 여부 확인
7. 필요할 때 restart 판단

 

journal 로그는 아래처럼 볼 수 있습니다.

 

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

 

예를 들어 nginx라면 이렇게 확인합니다.

 

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

 

이 명령어는 해당 서비스의 최근 systemd 로그 100줄을 보여줍니다.

status에서 대략적인 상태를 보고, journalctl로 더 자세한 로그를 확인하는 흐름이 좋습니다.

systemctl status
→ 현재 상태 확인

journalctl -u
→ 자세한 서비스 로그 확인

 

특정 서비스 하나가 아니라 실패한 서비스 전체를 한 번에 보고 싶다면 아래 글도 도움이 됩니다.

https://opsnote.tistory.com/32

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

 

11단계. 서비스가 active인데 접속이 안 될 때

systemctl status에서 active (running)이라고 나와도 사용자는 접속이 안 된다고 할 수 있습니다.

이때는 서비스가 떠 있는 것과 실제 접속이 되는 것을 구분해야 합니다.

확인 흐름은 이렇게 보면 됩니다.

1. 서비스 상태 확인
2. 포트 LISTEN 확인
3. 로컬 curl 확인
4. 애플리케이션 로그 확인
5. 방화벽, 보안그룹, 네트워크 확인

 

명령어로 보면 이런 식입니다.

 

systemctl status nginx --no-pager
ss -lntp | grep ':80'
curl -I http://localhost
journalctl -u nginx -n 100 --no-pager

 

즉 active (running)만 보고 “정상입니다”라고 말하면 안 됩니다.

서비스 상태는 정상이어도 포트, 설정, upstream, 네트워크 문제는 따로 있을 수 있습니다.

 

포트 확인은 아래 글에서 따로 정리했습니다.

https://opsnote.tistory.com/18

리눅스 서버 접속이 안 될 때 netstat보다 ss로 포트 확인하는 이유

 

12단계. restart가 필요할 때도 순서가 있습니다

상태와 로그를 확인한 뒤 실제로 재시작이 필요한 상황도 있습니다.

하지만 운영 서버에서 restart는 영향이 있는 작업입니다.

아래처럼 바로 실행하기 전에 먼저 확인합니다.

 

systemctl restart nginx

 

확인할 것은 아래입니다.

- 현재 서비스 상태
- 최근 에러 메시지
- 포트 사용 상태
- 설정 파일 오류 여부
- 재시작 시 사용자 영향
- 재시작 후 정상 확인 방법

 

재시작이 필요하다면 조치 후에도 끝난 것이 아닙니다.

다시 상태를 확인해야 합니다.

 

systemctl status nginx --no-pager
ss -lntp | grep ':80'
curl -I http://localhost
journalctl -u nginx -n 50 --no-pager

 

start, stop, restart 차이와 restart를 바로 누르면 위험한 이유는 아래 글에서 이어서 정리했습니다.

https://opsnote.tistory.com/28

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

 

재시작 후 정상 기동 확인은 아래 글과도 연결됩니다.

https://opsnote.tistory.com/29

리눅스 서버 restart 했으면 끝이 아닙니다? systemctl 재시작 후 정상 기동 확인하는 법

 

13단계. 운영 서버에서 주의할 점

운영 서버에서 status 확인은 부담이 적은 조회 작업입니다.

하지만 그다음 조치가 중요합니다.

주의할 점은 아래와 같습니다.

- 상태 확인 없이 restart부터 하지 않기
- failed 메시지를 캡처하거나 메모하기
- 재시작 전 영향도 생각하기
- 서비스명 정확히 확인하기
- 운영 로그를 외부에 그대로 공유하지 않기
- 비슷한 이름의 서비스를 착각하지 않기

 

특히 운영 서버에서 실제 서비스명을 잘못 보고 다른 서비스를 재시작하면 더 큰 문제가 될 수 있습니다.

예를 들어 비슷한 이름의 서비스가 여러 개 있을 수 있습니다.

nginx
nginx-backup
example-app
example-app-worker
example-app-batch

 

그래서 명령어를 실행하기 전에는 서비스명을 꼭 다시 확인하는 습관이 좋습니다.

 

systemctl status example-app --no-pager

 

실제 회사명, 내부 도메인, IP, 토큰, 계정명이 포함된 로그를 외부에 공유할 때는 반드시 마스킹해야 합니다.

14단계. 초보 운영자 기준 확인 순서

서비스가 안 뜬다고 느껴질 때는 아래 순서로 보는 것이 무난합니다.

1. systemctl status 서비스명
2. Active 상태 확인
3. Loaded와 enabled 여부 확인
4. Main PID 확인
5. 아래쪽 에러 메시지 확인
6. journalctl -u 서비스명으로 최근 로그 확인
7. ss -lntp로 포트 확인
8. curl로 로컬 응답 확인
9. 필요할 때 restart 판단
10. 조치 후 다시 status, 포트, 로그 확인

 

명령어로 정리하면 아래와 같습니다.

 

systemctl status nginx --no-pager
journalctl -u nginx -n 100 --no-pager
ss -lntp | grep ':80'
curl -I http://localhost

 

여기까지 보면 “서비스가 죽은 건지”, “떠 있는데 접속만 안 되는 건지”, “포트가 안 열린 건지” 정도는 방향이 잡힙니다.

15단계. 실무 보고 예시

서비스 상태를 확인한 뒤에는 이렇게 정리할 수 있습니다.

서비스 상태 확인 결과, nginx는 active(running) 상태로 확인됩니다.
다만 외부 접속 불가 현상이 있어 포트 LISTEN 상태 및 애플리케이션 로그를 추가 확인하겠습니다.

 

서비스가 failed라면 이렇게 쓸 수 있습니다.

서비스 상태 확인 결과, nginx가 failed 상태로 확인됩니다.
status 출력상 설정 파일 관련 오류 메시지가 확인되어,
설정 변경 이력과 상세 로그를 추가 확인하겠습니다.

 

포트 충돌이 의심된다면 이렇게 정리할 수 있습니다.

systemctl status 확인 결과 address already in use 메시지가 확인됩니다.
대상 포트를 사용 중인 프로세스를 ss 명령어로 추가 확인하겠습니다.

 

재시작이 필요한 상황이라면 이렇게 쓸 수 있습니다.

서비스 상태 및 최근 로그 확인 결과 재시작이 필요한 것으로 판단됩니다.
재시작 시 일시적인 접속 영향이 있을 수 있어 영향도 확인 후 진행하겠습니다.
조치 후 status, 포트 LISTEN, curl 응답을 재확인하겠습니다.

 

이렇게 정리하면 단순히 “서비스 안 떠서 재시작했습니다”보다 훨씬 낫습니다.

정리하면

리눅스 서버에서 서비스가 안 뜨는 것 같을 때는 바로 재시작하기보다 systemctl status로 상태를 먼저 확인하는 것이 좋습니다.

기본 명령어는 아래입니다.

 

systemctl status 서비스명

 

페이지 없이 보려면 아래처럼 확인합니다.

 

systemctl status 서비스명 --no-pager

 

최근 systemd 로그까지 보려면 아래처럼 확인합니다.

 

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

 

포트 상태도 함께 보려면 아래처럼 확인합니다.

 

ss -lntp | grep ':80'

서비스가 안 뜰 때는 바로 restart부터 하기보다, 먼저 systemctl status로 현재 상태를 확인하는 것이 좋습니다.

다만 status 결과만으로 원인을 모두 알 수는 없습니다.  
서비스가 왜 실패했는지, 최근에 어떤 에러가 남았는지는 로그를 함께 봐야 더 정확하게 판단할 수 있습니다.

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

https://opsnote.tistory.com/33

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

 

상태와 로그를 확인한 뒤 start, stop, restart를 어떻게 구분해서 써야 하는지는 아래 글에서 정리했습니다.

https://opsnote.tistory.com/28

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

리눅스 서버 장애 대응 전체 흐름은 아래 글에서 함께 보면 좋습니다.

https://opsnote.tistory.com/69

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