서버가 갑자기 재부팅될 때 원인 찾기

새벽 3시에 서버가 다운됐다는 알람이 울렸다. 운영 시간 중이 아니라서 사용자에겐 피해는 적지만, 왜 재부팅됐는지 알 수 없으면 같은 일이 또 반복될 수 있다.

서버 재부팅은 보통 세 가지 원인 중 하나다: 디스크 부족, 메모리 부족, 또는 커널 패닉.

현재 시스템 상태 확인

# 디스크 사용량
df -h

# 메모리 사용량
free -h

# 네트워크 연결 상태
sudo ss -lntp

# 최근 로그
sudo journalctl -n 80

디스크가 99% 찼다면? 메모리 스왑이 가득 찼다면? 그게 원인이다.

부팅 로그 확인

# 마지막 부팅 이유를 본다
sudo journalctl -b -1 -n 50
# -b -1: 이전 부팅, -n 50: 마지막 50줄

# OOM (Out of Memory) 관련 로그
sudo dmesg | grep -i "out of memory"

# 커널 패닉
sudo dmesg | grep -i "panic"

"Killed process" 메시지가 있다면 OOM killer가 프로세스를 강제 종료한 거다.

디스크 부족

디스크가 가득 찬 경우가 가장 흔하다.

# 어느 파일이 큰가?
sudo du -sh /*

# 로그 파일이 비정상적으로 커졌나?
ls -lh /var/log/

# 임시 파일?
ls -lh /tmp/

로그 파일이 제어 없이 계속 쌓이면 금방 디스크를 꽉 채운다. 로그 로테이션을 설정해야 한다.

# 오래된 로그 삭제
sudo find /var/log -type f -name "*.log" -mtime +30 -delete
# 30일 이상 된 로그 파일 삭제

메모리 부족

애플리케이션이 계속 메모리를 사용하고 반환하지 않으면 (메모리 누수), 언젠가는 메모리가 가득 찬다.

# 메모리를 많이 쓰는 프로세스
top -b -n 1 | head -20

# 또는
ps aux --sort=-%mem | head

특정 프로세스가 매번 부팅 후 점점 더 많은 메모리를 쓴다면, 그 프로세스에 메모리 누수가 있을 가능성이 높다.

시간 제약으로 인한 재부팅

Cron job이나 시스템 업데이트가 자동으로 재부팅을 예약했을 수도 있다.

# Cron job 확인
sudo crontab -l
sudo ls -la /etc/cron.d/

# 예약된 재부팅
shutdown -l  # 예약된 종료/재부팅 확인

실제 확인 순서

1. journalctl -b -1로 이전 부팅 로그 확인
2. df -h로 디스크 확인, free -h로 메모리 확인
3. 필요하면 du -sh /*로 어디가 큰지 확인
4. 로그 로테이션 설정 확인
5. 메모리 누수가 있는 프로세스 있는지 확인

마지막으로, 서버 재부팅은 일시적인 해결책이 아니다. 원인을 찾아서 고쳐야 다음에 안심할 수 있다. 특히 프로덕션 환경이라면, 재부팅 전에 반드시 로그를 백업해두자. 언젠가 또 필요할 수도 있다.