Linux Killed process 로그가 발생하는 원인과 해결 방법

작성자:

Linux 서버를 운영하다 보면 실행 중이던 프로그램이 특별한 오류 메시지 없이 갑자기 종료되는 경우가 있습니다. 로그를 확인해 보면 Killed process 또는 단순히 Killed라는 메시지만 남아 있는 경우가 있는데, 대부분은 Linux 커널이 프로세스를 강제로 종료했음을 의미합니다.

특히 메모리 부족으로 OOM(Out Of Memory) Killer가 동작했을 때 자주 발생하지만, 관리자에 의한 강제 종료, 컨테이너 리소스 제한, 시스템 정책 등에 의해 발생할 수도 있습니다.

이번 글에서는 Killed process 로그가 발생하는 원인과 확인 방법, 해결 방법을 자세히 알아보겠습니다.

Killed process란 무엇인가?

Killed process는 운영체제 또는 사용자가 실행 중인 프로세스를 강제로 종료했다는 의미입니다.

대표적인 로그 예시는 다음과 같습니다.

Killed process 12567 (java)

또는

Out of memory: Killed process 24581 (mysqld)

또는

Killed

단순히 Killed만 출력되는 경우에도 커널 로그를 함께 확인해야 실제 원인을 파악할 수 있습니다.

Killed process 로그가 발생하는 대표적인 원인

다음과 같은 경우에 자주 발생합니다.

  • OOM Killer 동작
  • 메모리 부족
  • Docker 메모리 제한 초과
  • Kubernetes Memory Limit 초과
  • 관리자의 kill -9 실행
  • 시스템 정책(Systemd)
  • 보안 프로그램 종료
  • 커널 오류
  • 애플리케이션 비정상 동작
  • 프로세스 제한 초과

실무에서는 OOM 여부를 가장 먼저 확인하는 것이 중요합니다.

1. 커널 로그 확인하기

가장 먼저 커널 로그를 확인합니다.

dmesg | grep -i killed

또는

journalctl -k

Killed process가 기록된 시간을 확인합니다.

2. OOM 로그 확인하기

OOM Killer가 원인인지 확인합니다.

dmesg | grep -i oom

또는

journalctl -k | grep -i oom

예시

Out of memory: Killed process 23124 (python)

이 로그가 있다면 메모리 부족이 원인입니다.

3. 메모리 사용량 확인하기

현재 메모리 상태를 확인합니다.

free -h

RAM과 Swap이 모두 부족한지 확인합니다.

4. 메모리를 많이 사용하는 프로세스 확인하기

top

또는

ps aux --sort=-%mem | head -20

메모리 사용량이 높은 프로세스를 확인합니다.

5. Swap 사용량 확인하기

swapon --show

또는

cat /proc/swaps

Swap까지 모두 사용 중이라면 OOM 발생 가능성이 높습니다.

6. Docker 환경 확인하기

Docker에서는 컨테이너 메모리 제한으로 인해 프로세스가 종료될 수 있습니다.

현재 상태 확인

docker stats

설정 확인

docker inspect 컨테이너명

Memory Limit을 확인합니다.

7. Kubernetes 환경 확인하기

Pod 상태를 확인합니다.

kubectl get pods

상세 정보 확인

kubectl describe pod POD_NAME

OOMKilled 상태인지 확인합니다.

8. 종료 신호(Signal) 확인하기

프로세스는 다양한 Signal에 의해 종료될 수 있습니다.

대표적인 Signal은 다음과 같습니다.

Signal의미
SIGTERM정상 종료 요청
SIGKILL강제 종료
SIGINTCtrl + C
SIGSEGV메모리 접근 오류

애플리케이션 로그와 함께 확인하는 것이 좋습니다.

9. Systemd 로그 확인하기

서비스가 Systemd에 의해 종료되었는지 확인합니다.

journalctl -u 서비스명

예시

journalctl -u nginx

서비스 재시작이나 종료 기록이 있는지 확인합니다.

10. 애플리케이션 로그 확인하기

프로세스 종료 직전의 로그를 확인합니다.

예시

tail -100 /var/log/application.log

또는

journalctl -xe

프로그램 내부 오류가 발생했는지 확인합니다.

Killed process 문제를 확인하는 순서

실무에서는 다음 순서대로 점검하는 것이 가장 효율적입니다.

  1. dmesg 확인
  2. journalctl -k 확인
  3. OOM 로그 확인
  4. free -h 확인
  5. top 확인
  6. Swap 확인
  7. Docker 상태 확인
  8. Kubernetes 상태 확인
  9. Systemd 로그 확인
  10. 애플리케이션 로그 확인

이 순서대로 확인하면 대부분의 원인을 빠르게 찾을 수 있습니다.

오류를 해결할 때 주의할 점

Killed process가 발생했다고 해서 무조건 메모리 부족이라고 단정해서는 안 됩니다.

관리자가 직접 kill 명령을 실행했거나, Docker/Kubernetes의 리소스 제한, Systemd 정책, 보안 프로그램 등에 의해 종료될 수도 있습니다. 따라서 반드시 커널 로그와 서비스 로그를 함께 분석해야 정확한 원인을 파악할 수 있습니다.

자주 묻는 질문

Killed만 출력되고 이유는 보이지 않습니다.

dmesg, journalctl -k, journalctl -xe를 확인하면 대부분의 경우 종료 원인을 찾을 수 있습니다.

OOMKilled와 Killed process는 같은 의미인가요?

관련은 있지만 동일한 의미는 아닙니다. OOMKilled는 메모리 부족으로 종료된 경우이고, Killed process는 다양한 이유로 강제 종료되었을 때 기록될 수 있습니다.

Docker에서도 Killed process가 발생할 수 있나요?

네. 메모리 제한이나 CPU 제한을 초과하면 컨테이너 내부 프로세스가 종료될 수 있습니다.

마무리

Killed process 로그는 Linux 서버에서 프로세스가 강제로 종료되었음을 나타내는 중요한 신호입니다. dmesg, journalctl, free, top, Docker 및 Kubernetes 로그를 함께 확인하면 대부분의 원인을 정확하게 분석할 수 있습니다. 특히 OOM Killer와의 연관성을 먼저 확인하면 문제 해결 시간을 크게 줄일 수 있습니다.

댓글 남기기