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

리눅스 서버에서 systemctl --failed 명령어로 실패한 systemd 서비스를 한 번에 확인하고 status, journalctl, 포트, 응답 상태를 순서대로 점검하는 방법을 설명하는 대표 이미지

 

리눅스 서버에서 서비스가 안 뜨거나, 서버 재기동 후 뭔가 이상할 때 보통 특정 서비스 하나를 찍어서 systemctl status로 확인합니다.

systemctl status nginx

 

그런데 실제 운영 상황에서는 어떤 서비스가 문제인지 처음부터 정확히 모를 때도 있습니다.

웹 서비스가 안 되는 것처럼 보이지만, 실제로는 관련된 worker 서비스가 실패했을 수도 있고, Redis나 DB 연동 서비스처럼 의존 서비스 쪽에 문제가 있을 수도 있습니다.

이럴 때 먼저 확인해볼 수 있는 명령어가 있습니다.

 

systemctl --failed

 

systemctl --failed는 systemd 기준으로 실패 상태에 있는 unit 목록을 한 번에 보여주는 명령어입니다.

이번 글에서는 리눅스 서버에서 systemctl --failed로 실패한 서비스를 확인하는 방법과, 확인 후 바로 restart하지 않고 어떤 순서로 봐야 하는지 정리합니다.

systemctl --failed는 언제 볼까?

systemctl --failed는 서버 안에서 실패 상태로 남아 있는 systemd unit을 확인할 때 사용합니다.

예를 들어 이런 상황에서 유용합니다.

- 서버 재기동 후 서비스가 안 올라온 경우
- 어떤 서비스가 실패했는지 빠르게 보고 싶은 경우
- 장애 원인을 찾기 전에 전체 상태를 훑고 싶은 경우
- 특정 서비스 status를 보기 전에 failed 목록을 확인하고 싶은 경우
- 여러 서비스가 동시에 이상해 보이는 경우

 

서비스가 안 뜬다고 바로 restart부터 누르기 전에, 실패한 서비스가 있는지 먼저 보면 방향을 잡기 좋습니다.

개별 서비스 상태를 확인하는 기본 흐름은 아래 글에서 정리했습니다.

https://opsnote.tistory.com/27

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

 

가상의 운영 상황 예시

예를 들어 서버 재기동 후 웹 서비스가 정상적으로 응답하지 않는다고 가정해보겠습니다.

[상황]
- 서버 재기동 완료
- 사용자는 웹 접속 불가 제보
- nginx 문제인지 애플리케이션 문제인지 아직 모름
- 어떤 서비스가 실패했는지 먼저 확인 필요

 

이때 바로 nginx만 restart하면 놓칠 수 있습니다.

 

systemctl restart nginx

 

먼저 실패한 unit이 있는지 확인합니다.

 

systemctl --failed

 

예를 들어 아래처럼 보일 수 있습니다.

UNIT                 LOAD   ACTIVE SUB    DESCRIPTION
app-worker.service   loaded failed failed App Worker Service
redis.service        loaded failed failed Redis Server

 

이 경우 웹 접속 문제처럼 보였지만, 실제로는 애플리케이션 worker나 Redis 실패가 같이 얽혀 있을 수 있습니다.

이제 할 일은 failed 목록을 보고 바로 restart하는 것이 아니라, 어떤 서비스부터 확인할지 순서를 잡는 것입니다.

1단계. systemctl --failed 기본 사용법

기본 사용법은 간단합니다.

systemctl --failed

 

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

UNIT                 LOAD   ACTIVE SUB    DESCRIPTION
nginx.service        loaded failed failed The nginx HTTP server
app-worker.service   loaded failed failed App Worker Service

 

처음 보면 항목이 조금 많아 보일 수 있습니다.

초보 운영자 기준으로는 우선 아래 항목을 보면 됩니다.

UNIT
→ 실패한 unit 이름

ACTIVE
→ 큰 범위의 상태

SUB
→ 세부 상태

DESCRIPTION
→ 서비스 설명

 

특히 UNIT에 나오는 서비스 이름을 확인한 뒤, 해당 서비스를 다시 systemctl status로 자세히 보면 됩니다.

 

systemctl status nginx --no-pager

 

2단계. failed 목록이 없다고 서버가 완전히 정상은 아닙니다

실패한 서비스가 없으면 보통 이런 식으로 나올 수 있습니다.

0 loaded units listed.

 

또는 배포판이나 환경에 따라 비슷한 문구로 표시될 수 있습니다.

이 경우에는 systemd 기준으로 failed 상태의 unit이 없다는 뜻입니다.

하지만 이것이 “서버에 아무 문제가 없다”는 뜻은 아닙니다.

예를 들어 이런 경우가 있을 수 있습니다.

- 서비스는 active 상태지만 애플리케이션 내부 오류가 있음
- 포트는 열려 있지만 응답이 500 오류임
- 서비스는 떠 있지만 외부 연동이 timeout임
- 방화벽, 보안그룹, 네트워크 문제가 있음
- 로그가 계속 쌓이지만 서비스 상태는 active임

 

즉, systemctl --failed는 전체 확인의 시작점이지 모든 장애를 찾아주는 만능 명령어는 아닙니다.

failed 목록이 없어도 포트, curl, 로그 확인은 필요할 수 있습니다.

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

https://opsnote.tistory.com/18

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

3단계. failed 서비스가 보이면 status로 자세히 보기

systemctl --failed에서 실패한 서비스가 보이면, 그다음은 status로 자세히 봅니다.

예를 들어 nginx.service가 failed로 보인다면 아래처럼 확인합니다.

 

systemctl status nginx --no-pager

 

또는 unit 이름을 그대로 써도 됩니다.

 

systemctl status nginx.service --no-pager

 

여기서 확인할 것은 아래입니다.

- Active 상태
- Main PID
- 실패 시각
- 최근 에러 메시지
- 설정 파일 관련 오류
- 포트 충돌 메시지
- 권한 오류 메시지
- 의존 서비스 실패 메시지

 

failed 목록만 보고 바로 restart를 누르기보다는, 왜 failed가 되었는지 먼저 보는 것이 안전합니다.

서비스가 안 뜰 때 systemctl status에서 무엇을 봐야 하는지는 아래 글에서 더 자세히 정리했습니다.

https://opsnote.tistory.com/27

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

 

4단계. journalctl로 해당 서비스 로그 확인하기

status만으로 부족하면 journalctl로 해당 서비스 로그를 확인합니다.

 

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

 

최근 100줄을 보는 명령어입니다.

조금 더 많이 보고 싶다면 숫자를 늘릴 수 있습니다.

 

journalctl -u nginx -n 300 --no-pager

 

실패 원인이 설정 파일 문제라면 이런 키워드가 보일 수 있습니다.

syntax error
invalid configuration
failed to start
permission denied
address already in use
timeout
not found
connection refused

 

특히 address already in use가 보이면 포트 충돌 가능성이 있습니다.

이때는 포트 상태도 같이 봐야 합니다.

 

ss -lntp

 

특정 포트만 보면 아래처럼 확인합니다.

 

ss -lntp | grep ':80'

 

로그를 볼 때는 에러 한 줄만 보고 단정하지 말고, 앞뒤 흐름도 같이 보는 것이 좋습니다.

로그 확인 기본 흐름은 아래 글들과 이어서 보면 좋습니다.

https://opsnote.tistory.com/20

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

 

https://opsnote.tistory.com/21

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

 

https://opsnote.tistory.com/24

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

 

5단계. failed 상태와 inactive 상태는 다릅니다

초보 운영자가 헷갈리기 쉬운 부분이 있습니다.

failed와 inactive는 다릅니다.

failed
→ 서비스가 시작에 실패했거나 비정상 종료된 상태

inactive
→ 현재 실행 중이 아닌 상태

 

예를 들어 failed는 아래처럼 볼 수 있습니다.

Active: failed

 

이 상태는 서비스가 실행 실패 상태로 남아 있다는 의미입니다.

반면 inactive는 아래처럼 보일 수 있습니다.

Active: inactive (dead)

 

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

하지만 inactive가 항상 장애는 아닙니다. 어떤 서비스는 원래 필요할 때만 실행되고 평소에는 inactive일 수 있습니다.

정리하면 이렇게 볼 수 있습니다.

failed
→ 실패 원인 확인 필요

inactive
→ 원래 상시 실행 서비스인지 먼저 확인 필요

active
→ 실행 중이지만 실제 응답 정상 여부는 추가 확인 필요

 

그래서 systemctl --failed에 보이는 서비스는 우선 실패 원인을 봐야 하고, inactive 서비스는 그 서비스가 원래 항상 떠 있어야 하는지 먼저 판단해야 합니다.

6단계. failed가 있다고 바로 restart하면 안 됩니다

systemctl --failed에서 실패한 서비스가 보이면 바로 아래 명령어를 치고 싶을 수 있습니다.

 

systemctl restart nginx

 

하지만 운영 서버에서는 조심해야 합니다.

failed 상태에는 원인 단서가 남아 있을 수 있습니다.

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

permission denied
address already in use
syntax error
missing environment file

 

이 상태에서 바로 restart를 반복하면 원인 확인이 더 어려워질 수 있습니다.

먼저 아래 순서로 봅니다.

1. systemctl --failed로 실패 목록 확인
2. systemctl status 서비스명으로 상태 확인
3. journalctl -u 서비스명으로 로그 확인
4. 포트 충돌 또는 설정 오류 확인
5. 업무 영향도 확인
6. 필요할 때 restart 판단

 

restart는 첫 조치가 아니라 상태 확인 후 판단하는 조치입니다.

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

https://opsnote.tistory.com/28

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

 

7단계. 서버 재기동 후 failed 확인 순서

서버를 재기동한 뒤 서비스가 정상인지 확인할 때는 아래 순서가 좋습니다.

1. 실패한 서비스 목록 확인
2. 문제 서비스 status 확인
3. journalctl로 최근 로그 확인
4. 포트 LISTEN 상태 확인
5. curl로 로컬 응답 확인
6. 필요 시 조치 판단
7. 조치 후 다시 failed 목록 확인

 

명령어로 보면 이렇게 정리할 수 있습니다.

 

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

 

필요한 조치를 한 뒤에는 다시 확인합니다.

 

systemctl --failed

 

조치 후에도 failed 목록에 남아 있다면 아직 문제가 해결되지 않았을 가능성이 있습니다.

서버 전체를 재기동해야 하는 상황이라면 사전에 확인할 항목이 더 많습니다. 재기동 전 체크리스트는 아래 글에서 정리했습니다.

https://opsnote.tistory.com/19

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

 

8단계. failed 서비스가 여러 개일 때는 의존 관계를 봅니다

실패한 서비스가 여러 개 보일 때는 당황하기 쉽습니다.

이럴 때는 무작정 위에서부터 하나씩 restart하지 말고, 서비스 관계를 먼저 봐야 합니다.

예를 들어 이런 식으로 보일 수 있습니다.

app.service
app-worker.service
redis.service

 

이 경우 app-worker가 실패한 원인이 Redis 미기동 때문일 수도 있습니다.

그래서 failed 목록을 볼 때는 단순히 개수만 보지 말고, 어떤 서비스들이 함께 실패했는지 봐야 합니다.

확인 순서는 보통 이렇게 잡습니다.

1. 공통 의존 서비스 확인
2. DB, Redis, MQ 같은 기반 서비스 확인
3. 그다음 애플리케이션 서비스 확인
4. 마지막으로 worker, batch 서비스 확인

 

물론 서버마다 구조가 다르기 때문에 정답은 없습니다.

중요한 것은 failed 목록을 보고 “무엇부터 봐야 할지” 순서를 잡는 것입니다.

9단계. 실패 서비스가 업무 영향이 있는지 판단하기

failed 서비스가 있다고 해서 모두 같은 중요도는 아닙니다.

어떤 서비스는 업무 서비스에 직접 영향을 줄 수 있고, 어떤 서비스는 보조 서비스일 수 있습니다.

우선 아래 기준으로 봅니다.

- 사용자 요청을 직접 처리하는 서비스인지
- 웹, WAS, DB, Redis, MQ처럼 주요 경로에 있는 서비스인지
- 배치나 worker처럼 후속 처리를 담당하는 서비스인지
- 이중화되어 있는 서비스인지
- 대기 노드에서만 동작하는 서비스인지
- 원래 자동 기동 대상인지
- 최근 작업 또는 배포와 관련이 있는지

 

예를 들어 웹서버가 failed라면 접속 영향 가능성이 큽니다.

반면 테스트용 서비스나 대기 노드의 보조 서비스가 failed라면 운영 기준에 따라 영향이 없을 수도 있습니다.

그래서 failed 목록을 보고 바로 조치하기보다 “이 서비스가 어떤 역할인지”를 먼저 확인해야 합니다.

10단계. 자동 기동 설정도 같이 확인하기

서버 재기동 후 특정 서비스가 failed 또는 inactive 상태라면 자동 기동 설정도 같이 봐야 합니다.

 

systemctl is-enabled nginx

 

결과가 enabled라면 서버 재기동 후 자동으로 실행되도록 설정된 상태입니다.

enabled

 

결과가 disabled라면 서버 재기동 후 자동으로 올라오지 않을 수 있습니다.

disabled

 

하지만 enabled라고 해서 실행 성공까지 보장하는 것은 아닙니다.

정리하면 이렇게 볼 수 있습니다.

enabled + failed
→ 자동 기동 시도는 했지만 기동 실패 가능성

disabled + inactive
→ 자동 기동 설정이 꺼져 있거나 수동 기동 대상일 가능성

active + disabled
→ 지금은 떠 있지만 다음 재기동 후 자동으로 안 뜰 수 있음

 

enable, disable 차이와 자동 기동 설정 확인은 아래 글에서 정리했습니다.

https://opsnote.tistory.com/30

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

 

11단계. 조치 후에는 정상 상태를 다시 확인합니다

문제를 확인하고 조치를 했다면 다시 확인해야 합니다.

예를 들어 restart가 필요한 상황이라면 조치 후 아래를 봅니다.

 

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

 

여기서 확인할 것은 아래입니다.

- 서비스가 active 상태인지
- 포트가 LISTEN 상태인지
- 로컬 curl 응답이 정상인지
- 최근 로그에 추가 에러가 없는지
- systemctl --failed 목록에서 사라졌는지

 

재시작 후 정상 기동 확인 흐름은 아래 글에서도 이어서 볼 수 있습니다.

https://opsnote.tistory.com/29

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

 

12단계. failed 상태를 초기화하는 reset-failed

조치를 완료했는데도 failed 목록에 예전 실패 기록이 남아 있는 경우가 있습니다.

이럴 때는 reset-failed 명령어가 있습니다.

 

systemctl reset-failed

 

특정 서비스만 초기화하려면 아래처럼 실행할 수 있습니다.

 

systemctl reset-failed nginx

 

주의할 점은 이 명령어가 문제를 해결하는 명령은 아니라는 것입니다.

reset-failed는 failed 상태 기록을 초기화하는 명령입니다.

서비스가 실제로 정상인지 먼저 확인한 뒤 사용해야 합니다.

초보 운영자 기준으로는 이렇게 기억하면 됩니다.

reset-failed
→ 실패 기록 초기화

restart
→ 서비스 재시작

status
→ 현재 상태 확인

 

실패 원인을 해결하지 않고 reset-failed만 실행하면, 목록에서는 사라져도 문제는 그대로 남아 있을 수 있습니다.

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

systemctl --failed는 조회 명령이라 부담이 적습니다.

하지만 이후 조치가 중요합니다.

운영 서버에서는 아래를 조심해야 합니다.

- failed 목록만 보고 바로 restart하지 않기
- 서비스 영향도 확인하기
- 여러 서비스가 실패했으면 의존 관계 생각하기
- reset-failed를 해결 조치로 착각하지 않기
- disabled 또는 inactive 서비스와 failed 서비스를 구분하기
- 로그 공유 시 실제 서버명, IP, 경로 마스킹하기

 

특히 여러 서비스가 동시에 failed라면 단일 서비스 문제가 아닐 수 있습니다.

디스크 용량 부족, 설정 파일 공통 문제, 의존 서비스 미기동, 공통 환경 변수 누락 같은 원인도 같이 봐야 합니다.

14단계. 초보 운영자 기준 확인 흐름

초보 운영자 기준으로는 아래 흐름이 무난합니다.

systemctl --failed
→ systemctl status 서비스명
→ journalctl -u 서비스명
→ ss 또는 curl로 실제 동작 확인
→ 필요 시 조치
→ 조치 후 다시 systemctl --failed

 

예시 명령어는 아래처럼 쓸 수 있습니다.

 

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

 

이렇게 보면 “어떤 서비스가 실패했는지”와 “조치 후 failed 상태가 남아 있는지”를 같이 확인할 수 있습니다.

15단계. 실무 보고 예시

failed 서비스가 확인되지 않았을 때는 이렇게 정리할 수 있습니다.

systemctl --failed 기준 failed 상태의 서비스는 확인되지 않았습니다.
다만 서비스 응답 지연이 있어 포트 상태 및 애플리케이션 로그를 추가 확인하겠습니다.

 

failed 서비스가 확인된 경우는 이렇게 쓸 수 있습니다.

systemctl --failed 확인 결과 nginx.service가 failed 상태로 확인되었습니다.
status 및 journalctl 로그 기준 설정 파일 관련 오류 메시지가 확인되어 설정 내용을 추가 확인하겠습니다.

 

여러 서비스가 실패한 경우는 이렇게 정리할 수 있습니다.

systemctl --failed 확인 결과 app.service와 app-worker.service가 failed 상태로 확인되었습니다.
두 서비스의 로그를 확인한 뒤 공통 의존 서비스 문제 여부를 함께 확인하겠습니다.

 

조치 후에는 이렇게 쓸 수 있습니다.

조치 후 systemctl --failed 재확인 결과 failed 상태의 서비스는 확인되지 않습니다.
서비스 상태 및 포트 LISTEN 상태도 정상 확인했습니다.

 

reset-failed를 사용한 경우에는 이렇게 정리하면 좋습니다.

서비스 정상 기동 및 포트 응답 확인 후 기존 failed 기록을 reset-failed로 초기화했습니다.
초기화 후 systemctl --failed 기준 실패 상태의 서비스는 확인되지 않습니다.

 

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

정리하면

리눅스 서버에서 실패한 서비스를 한 번에 확인하려면 아래 명령어를 사용합니다.

 

systemctl --failed

 

실패한 서비스가 보이면 바로 조치하기보다 먼저 자세히 확인합니다.

 

systemctl status 서비스명 --no-pager

 

로그는 journalctl로 확인할 수 있습니다.

 

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

 

포트와 응답도 함께 확인합니다.

 

ss -lntp | grep ':포트'
curl -I http://localhost

 

조치 후에는 다시 failed 목록을 확인합니다.

 

systemctl --failed

 

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

서비스가 이상할 때는 하나씩 찍어보기 전에 systemctl --failed로 실패한 서비스 목록부터 확인하세요.

단, failed 목록이 보인다고 바로 restart하지 말고, status와 journalctl로 원인을 먼저 확인해야 합니다.

서비스 확인도 결국 같습니다.

 

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

 

서비스가 이상할 때는 하나씩 찍어보기 전에 systemctl --failed로 실패한 서비스 목록부터 확인하는 것이 좋습니다.

다만 failed 목록이 보인다고 바로 restart부터 하면 안 됩니다.  
먼저 systemctl status로 서비스 상태를 보고, journalctl로 최근 로그를 확인한 뒤 원인을 판단해야 합니다.

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

https://opsnote.tistory.com/27

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

서비스 실패 원인을 journalctl 로그로 확인하는 방법은 아래 글에서 정리했습니다.

https://opsnote.tistory.com/33

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

 

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

https://opsnote.tistory.com/69

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