여기서는 멈추세요
- 원격 접속만 가능하고 콘솔·스냅샷이 없으면 부팅 관련 설정을 변경하거나 재부팅하지 않습니다.
- root·boot·network-online 같은 핵심 unit의 의존성을 이해하지 못했다면 비활성화하지 않습니다.
BOOT DIAGNOSIS
Ubuntu 부팅이 느리거나 systemd unit이 실패할 때
접속 가능한 시스템이나 복구 콘솔에서 부팅 시간을 분해하고 실패 unit, critical chain과 직전 부팅 로그를 확인합니다.Ubuntu boot slowsystemd-analyze blamefailed unitemergency modeA start job is running
환경Ubuntu 22.04·24.04 LTS · systemd · 접속 또는 복구 콘솔 가능 환경
분류서비스
검토일2026-08-27
진행5단계 · 조회 우선
SAFE OPERATING BOUNDARY
중단·복구 기준부터 확인하세요
복구 기준
변경한 unit과 drop-in을 별도 백업해 두고 문제가 생기면 복구 콘솔에서 원본을 복원한 뒤 daemon-reload를 수행합니다.
담당자에게 전달할 자료
- systemd-analyze time·blame·critical-chain 결과
- systemctl --failed와 문제 unit의 status·cat 출력
- 현재·직전 부팅의 최초 관련 경고와 장치 로그
BEFORE YOU START
이런 증상에서 시작합니다
- 부팅 후 로그인까지 오래 걸림
- systemctl --failed에 unit 표시
- A start job is running 메시지
- 복구 콘솔 또는 emergency mode 진입
CHECK THE BRANCH
놓치기 쉬운 원인 분기
부팅은 성공하지만 느림
blame의 긴 시간만으로 원인을 확정하지 말고 critical-chain에서 의존성과 실제 대기 순서를 함께 확인합니다.
failed unit이 존재
unit 자체 오류와 선행 의존성 실패를 구분하고 현재 부팅의 최초 오류부터 읽습니다.
emergency mode 진입
fstab·파일시스템·루트 장치 오류 가능성이 있으므로 원격 SSH보다 콘솔을 유지하고 저장장치 가이드로 연결합니다.
FOLLOW THE FLOW
순서대로 확인하기
조회시스템을 변경하지 않는 확인 단계
전체 부팅 시간과 실패 unit 확인
커널·initrd·userspace 시간을 분리하고 현재 실패 상태인 unit을 확인합니다.
부팅 시간 요약
systemd-analyze time실패 unit
systemctl --failed --no-pager결과 읽기
userspace가 길면 unit 의존성을, kernel이나 initrd가 길면 저장장치·드라이버·초기 부팅 범위를 우선 봅니다.
다음 판단
느린 부팅과 명시적 unit 실패 중 어느 분기인지 기록합니다.
조회시스템을 변경하지 않는 확인 단계
느린 unit과 critical chain 비교
blame은 초기화에 걸린 시간 목록이고 critical-chain은 부팅 경로의 시간 의존성을 보여줍니다.
느린 unit 상위 목록
systemd-analyze blame --no-pager | head -30부팅 임계 경로
systemd-analyze critical-chain --no-pager결과 읽기
blame 상위여도 다른 unit을 막지 않았다면 전체 지연 원인이 아닐 수 있습니다.
다음 판단
임계 경로에서 지연이 시작된 unit 이름과 시간을 기록합니다.
조회시스템을 변경하지 않는 확인 단계
현재와 직전 부팅의 최초 오류 확인
마지막 오류만 보지 말고 의존 실패를 일으킨 최초 경고와 장치 메시지를 찾습니다.
부팅 목록
journalctl --list-boots --no-pager현재 부팅 경고
journalctl -b -p warning --no-pager직전 부팅 경고
journalctl -b -1 -p warning --no-pager결과 읽기
dependency failed 앞의 mount, device, timeout 또는 service 오류를 우선 원인 후보로 봅니다.
다음 판단
문제 unit과 같은 시각의 커널·서비스 로그를 대조합니다.
주의서버 부하나 권한을 고려할 단계
문제 unit의 정의와 의존성 검증
UNIT_NAME을 실제 이름으로 바꾸고 drop-in과 실행 환경을 확인합니다.
unit 상태
systemctl status UNIT_NAME --no-pager -l원본과 drop-in
systemctl cat UNIT_NAME주요 의존 관계
systemctl list-dependencies UNIT_NAME --all --no-pagerunit 파일 문법
systemd-analyze verify /etc/systemd/system/UNIT_NAME결과 읽기
ExecStart 경로, After·Requires, timeout, mount/device 의존성과 drop-in 충돌을 확인합니다.
다음 판단
설정 변경 전에 원본과 drop-in 파일을 보관하고 영향 범위를 승인받습니다.
변경데이터·서비스 상태가 달라질 수 있는 단계
원인을 수정한 뒤 실패 상태와 부팅 경로 재검증
실패 원인을 수정하지 않은 채 reset-failed만 실행해도 장애는 해결되지 않습니다.
변경 단계입니다. 실행 전 대상 이름과 경로, 서비스 중단 영향, 복구 방법을 다시 확인하세요.
unit 설정 다시 읽기
sudo systemctl daemon-reload실패 상태 초기화
sudo systemctl reset-failed UNIT_NAME승인된 unit 재시작
sudo systemctl restart UNIT_NAME상태 재확인
systemctl status UNIT_NAME --no-pager -l임계 경로 재확인
systemd-analyze critical-chain --no-pager결과 읽기
unit이 active이고 실패 목록에서 사라졌으며 동일 의존 경로의 지연이 줄어야 합니다.
다음 판단
재부팅 검증은 콘솔과 롤백 수단을 확보한 별도 변경 창에서 수행합니다.
PRIMARY REFERENCES
공식 문서
배포판과 버전에 따라 옵션·로그 위치가 다를 수 있습니다. 실행 전 서버의 --help와 로컬 매뉴얼을 함께 확인하세요.