리눅스 시스템 장애는 자원 → 프로세스 → 권한 → 로그 순으로 좁힌다
서버가 “느리다/멈췄다/안 된다”일 때 무엇부터 볼지는 대체로 정해져 있다. 추측 대신 이 네 계층을 순서대로 확인하면 원인이 빠르게 드러난다.
1) 자원 — 가장 흔한 진짜 원인
df -h; df -i # 디스크 용량과 inode(둘 다!)
free -h; top # 메모리·load
여기서 두 가지 함정을 특히 조심한다. “디스크가 꽉 찼는데 df는 여유”면 삭제됐지만 프로세스가 잡고 있는 파일 핸들이다(lsof +L1). 용량은 남는데 파일 생성 실패면 inode 고갈이다(df -i).
2) 프로세스와 한도
fd 한도(ulimit -n), 좀비·D 상태(uninterruptible) 프로세스, 스레드 폭증을 본다. “too many open files”는 코드 버그가 아니라 한도인 경우가 많다.
3) 권한
umask·setgid·ACL·소유권, 그리고 SELinux/AppArmor. “권한이 맞는데 거부”면 표준 권한 위에 강제 접근 제어가 막는 것이다(ausearch, getenforce).
4) 로그
journalctl -u <svc> --since "10 min ago"
dmesg -T | tail # OOM killer, I/O 에러, 파일시스템 read-only 전환dmesg의 OOM killer나 I/O 에러로 파일시스템이 read-only로 전환된 흔적은, 앱 로그만 봐선 절대 안 보이는 근본 원인일 때가 많다.
정리
자원(용량·inode·삭제된 핸들) → 프로세스·fd 한도 → 권한·강제 접근 제어 → 커널/서비스 로그. 증상 이름을 원인으로 단정하지 않는 것이 리눅스에서도 첫 규칙이다.
빠른 진단 체크리스트
- 자원→프로세스→권한→로그 순으로 좁힌다
df -h와df -i(inode)를 함께 본다- 디스크 가득인데 df는 여유면 삭제된 파일 핸들(lsof +L1)이다
- 용량은 남는데 파일 생성 실패면 inode 고갈이다
- too many open files면
ulimit -n한도를 본다 - 권한이 맞는데 거부면 SELinux·AppArmor를 본다
journalctl -u로 서비스 로그를 본다dmesg에서 OOM killer·I/O 에러·ro 전환을 본다