학습 목표

systemd 기반 서버에서 서비스 장애가 발생했을 때, 실패 서비스를 찾고 원인 로그를 확인하는 기본 절차를 학습합니다.

운영자는 서비스를 재시작하는 사람이라기보다, 왜 실패했는지 근거를 남기고 복구 순서를 판단하는 사람입니다.

왜 초동 대응 순서가 중요한가

서비스 장애가 발생하면 급하게 restart부터 실행하고 싶어집니다.

하지만 원인 로그를 확인하지 않고 재시작하면 실패 원인이 사라지거나, 같은 장애가 반복될 수 있습니다.

초동 대응은 “목록 확인 → 상세 상태 확인 → 로그 확인 → 조치” 순서로 진행해야 합니다.

1) 실패 서비스 목록 확인

systemctl --failed

systemctl

systemctl은 systemd 서비스를 관리하는 명령어입니다.

서비스 시작, 중지, 재시작, 상태 확인을 모두 담당합니다.

--failed

--failed는 실패 상태에 있는 유닛만 보여줍니다.

서버에 서비스가 많을수록 전체 목록을 보는 것보다 실패 목록만 먼저 보는 것이 효율적입니다.

운영에서는 이 출력 결과를 장애 티켓에 그대로 남기는 경우가 많습니다.

2) 개별 서비스 상세 확인

systemctl status nginx.service -l

status

status는 서비스의 현재 상태, 최근 로그, 프로세스 정보, 종료 코드를 보여줍니다.

active, failed, inactive 상태를 보고 서비스가 실제로 동작 중인지 판단합니다.

-l 옵션

-l은 긴 로그 라인을 줄이지 않고 보여줍니다.

오류 메시지가 길게 출력되는 서비스에서는 -l 옵션이 없으면 중요한 경로 또는 에러 원인이 잘릴 수 있습니다.

3) journalctl로 원인 로그 확인

journalctl -u nginx.service -n 100 --no-pager
journalctl -p err -b --no-pager | head -n 30

journalctl -u

journalctl -u 서비스명은 특정 서비스 로그만 조회합니다.

서비스 단위로 로그를 좁히면 전체 시스템 로그에서 헤매지 않아도 됩니다.

-n 100

최근 100줄만 확인합니다.

장애 초동에는 전체 로그보다 최근 실패 시점 근처 로그가 더 중요합니다.

-p err -b

현재 부팅 이후의 error 등급 로그만 봅니다.

서비스 자체 문제인지, 시스템 전반의 문제인지 구분할 때 도움이 됩니다.

신규직원 실습 절차

1. 실패 서비스 목록을 추출합니다.

2. 각 서비스의 상태와 최근 로그를 확인합니다.

3. 오류가 많은 서비스를 집계합니다.

4. 근거 로그를 남긴 뒤 복구 순서를 정합니다.

연계실습

• 연계실습 텍스트: systemd 실패 서비스 목록 및 집계

• 실습 바로 시작: 문제 216 실습 시작하기 →

연계 실습

이 글에서 다룬 내용을 직접 명령어로 쳐 보면 훨씬 오래 남습니다.

• RHCSA 서비스 관리 실습 문제 →
• 리눅스마스터 실기 기출 유형 풀이 →