systemd 저널로 서비스 실패 추적 - journalctl 디버깅 — 실습 Lab

INCIDENT RESPONSE

0 / 5 단계 완료

📚 PREREQUISITES

Labsystemd-service-register

Theorylinux/systemd-journal-advanced

Theorylinux/systemd-services

TRACK

LINUX

SLA

40분

SEV

SEV-2

PHASES

3단계

ENV

local

INCOMING TICKET

“장애: "systemctl status가 failed인데 한 줄 메시지만 보여요. 진짜 원인 로그를 어디서 봐야 하죠? 재부팅하니 그 전 로그도 사라졌어요."”

YOUR ROLE

리눅스 서버 운영 엔지니어인 당신이

IMPACT IF UNRESOLVED

서비스 실패 근본 원인을 못 찾아 복구·재발 방지 지연. 저널 비영속이면 재부팅 후 증거 소실.

🚨INCIDENT BRIEF

"서비스가 failed예요." systemctl status myapp을 보니 빨간 글씨로 한 줄 - "main process exited, code=exited, status=1/FAILURE".

그런데 왜 1로 죽었는지, 그 직전에 무슨 일이 있었는지는 안 보입니다. 게다가 재부팅했더니 그 전 로그가 통째로 사라졌습니다.

systemctl status는 요약 몇 줄만 보여줍니다. 진짜 원인은 저널(journal)에 있습니다 - journalctl로 그 유닛의 전체 로그를

시간·부팅·우선순위로 필터해 봐야 합니다. 그리고 저널이 비영속(volatile)이면 재부팅 시 증거가 사라지므로 영속화가 필요합니다.

저널을 제대로 읽고, 누락·소실 함정을 다뤄 실패의 근본 원인을 찾습니다.

⏱ 40분📊 중급🔧 3단계#linux#systemd#journalctl#journal

MISSION

journalctl로 유닛 실패 로그 추적

status의 한 줄 너머, 그 유닛의 전체 로그를 시간·부팅 기준으로 봐서 실패 직전 맥락을 찾는다

누락 로그 - rate-limit·stdout 캡처 점검

로그가 비어 보이거나 끊겼을 때, journald rate-limit이나 앱이 저널로 안 보내는 문제를 가른다

저널 영속화 - 재부팅 후 증거 보존

재부팅 시 로그가 사라지지 않도록 저널을 영속(persistent) 저장으로 설정하고 확인한다

📌 선수 지식

ℹ️ 실습 환경

환경: local

필요 도구: systemctl, journalctl, systemd-analyze

🔒

실습 실행은 Pro 플랜 전용입니다

인시던트 브리프와 학습 자료는 지금 바로 확인할 수 있습니다. 실제 실습 진행 및 터미널 사용은 Pro 플랜에서 가능합니다.

>_ LAB TERMINAL↔ 너비 조절

NOTES