<h2>학습 목표</h2><p><code data-backticks="1">systemd</code> 기반 서버에서 서비스 장애가 발생했을 때, 실패 서비스를 찾고 원인 로그를 확인하는 기본 절차를 학습합니다.</p><p><br class="ProseMirror-trailingBreak"></p><p>운영자는 서비스를 재시작하는 사람이라기보다, 왜 실패했는지 근거를 남기고 복구 순서를 판단하는 사람입니다.</p><div contenteditable="false"><hr></div><h2>왜 초동 대응 순서가 중요한가</h2><p>서비스 장애가 발생하면 급하게 <code data-backticks="1">restart</code>부터 실행하고 싶어집니다.</p><p><br class="ProseMirror-trailingBreak"></p><p>하지만 원인 로그를 확인하지 않고 재시작하면 실패 원인이 사라지거나, 같은 장애가 반복될 수 있습니다.</p><p><br class="ProseMirror-trailingBreak"></p><p>초동 대응은 “목록 확인 → 상세 상태 확인 → 로그 확인 → 조치” 순서로 진행해야 합니다.</p><div contenteditable="false"><hr></div><h2>1) 실패 서비스 목록 확인</h2><div data-language="bash" class="toastui-editor-ww-code-block"><pre><code data-language="bash">systemctl --failed</code></pre></div><h3>systemctl</h3><p><code data-backticks="1">systemctl</code>은 systemd 서비스를 관리하는 명령어입니다.</p><p><br class="ProseMirror-trailingBreak"></p><p>서비스 시작, 중지, 재시작, 상태 확인을 모두 담당합니다.</p><h3>--failed</h3><p><code data-backticks="1">--failed</code>는 실패 상태에 있는 유닛만 보여줍니다.</p><p><br class="ProseMirror-trailingBreak"></p><p>서버에 서비스가 많을수록 전체 목록을 보는 것보다 실패 목록만 먼저 보는 것이 효율적입니다.</p><p><br class="ProseMirror-trailingBreak"></p><p>운영에서는 이 출력 결과를 장애 티켓에 그대로 남기는 경우가 많습니다.</p><div contenteditable="false"><hr></div><h2>2) 개별 서비스 상세 확인</h2><div data-language="bash" class="toastui-editor-ww-code-block"><pre><code data-language="bash">systemctl status nginx.service -l</code></pre></div><h3>status</h3><p><code data-backticks="1">status</code>는 서비스의 현재 상태, 최근 로그, 프로세스 정보, 종료 코드를 보여줍니다.</p><p><br class="ProseMirror-trailingBreak"></p><p><code data-backticks="1">active</code>, <code data-backticks="1">failed</code>, <code data-backticks="1">inactive</code> 상태를 보고 서비스가 실제로 동작 중인지 판단합니다.</p><h3>-l 옵션</h3><p><code data-backticks="1">-l</code>은 긴 로그 라인을 줄이지 않고 보여줍니다.</p><p><br class="ProseMirror-trailingBreak"></p><p>오류 메시지가 길게 출력되는 서비스에서는 <code data-backticks="1">-l</code> 옵션이 없으면 중요한 경로 또는 에러 원인이 잘릴 수 있습니다.</p><div contenteditable="false"><hr></div><h2>3) journalctl로 원인 로그 확인</h2><div data-language="bash" class="toastui-editor-ww-code-block"><pre><code data-language="bash">journalctl -u nginx.service -n 100 --no-pager
journalctl -p err -b --no-pager | head -n 30</code></pre></div><h3>journalctl -u</h3><p><code data-backticks="1">journalctl -u 서비스명</code>은 특정 서비스 로그만 조회합니다.</p><p><br class="ProseMirror-trailingBreak"></p><p>서비스 단위로 로그를 좁히면 전체 시스템 로그에서 헤매지 않아도 됩니다.</p><h3>-n 100</h3><p>최근 100줄만 확인합니다.</p><p><br class="ProseMirror-trailingBreak"></p><p>장애 초동에는 전체 로그보다 최근 실패 시점 근처 로그가 더 중요합니다.</p><h3>-p err -b</h3><p>현재 부팅 이후의 error 등급 로그만 봅니다.</p><p><br class="ProseMirror-trailingBreak"></p><p>서비스 자체 문제인지, 시스템 전반의 문제인지 구분할 때 도움이 됩니다.</p><div contenteditable="false"><hr></div><h2>신규직원 실습 절차</h2><ol><li><p>실패 서비스 목록을 추출합니다.</p></li><li><p>각 서비스의 상태와 최근 로그를 확인합니다.</p></li><li><p>오류가 많은 서비스를 집계합니다.</p></li><li><p>근거 로그를 남긴 뒤 복구 순서를 정합니다.</p></li></ol><div contenteditable="false"><hr></div><h2>연계실습</h2><ul><li><p>연계실습 텍스트: systemd 실패 서비스 목록 및 집계</p></li><li><p>실습 바로 시작: <a href="https://learnix.kr/server_cbt?id=216&amp;amp;from=%2Flearn_linux">문제 216 실습 시작하기 →</a></p></li></ul><div contenteditable="false"><hr></div>

<!-- publish_key:rocky8-day04-post -->

---

## 연계 실습

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

- [RHCSA 서비스 관리 실습 문제 →](https://learnix.kr/rhcsa)
- [리눅스마스터 실기 기출 유형 풀이 →](https://learnix.kr/linuxmaster)