Linux 서버 디스크가 가득 찼을 때
무작정 로그를 지우지 않고 파일시스템, inode, 큰 경로, 열린 삭제 파일 순서로 원인을 좁힙니다.
디스크 fullNo space leftdf
진단 순서 시작 →SERVER TROUBLESHOOTING PLAYBOOK
서버 이슈를
순서대로 해결하세요
Linux·Ubuntu 서버에서 자주 만나는 문제와 기본 점검 항목을 조회 명령어부터 결과 해석, 안전한 조치와 재확인까지 한 단계씩 안내합니다.- 1증상 검색
오류 문구나 현상으로 관련 가이드를 찾습니다.
- 2조회부터 실행
변경 없는 명령어로 장애 범위를 좁힙니다.
- 3결과 해석
출력에서 무엇을 확인할지 바로 안내합니다.
- 4조치 후 검증
위험도를 확인하고 같은 기준으로 재검증합니다.
SEARCH BY SYMPTOM
증상이나 확인 항목으로 찾으세요
오류 문구, 현상 또는 확인하려는 항목을 입력하면 관련 진단 순서를 보여드립니다.43개의 단계별 가이드
용량은 남았는데 파일 생성이 안 될 때
inode 고갈 여부를 확인하고 작은 파일이 집중된 디렉터리를 찾아 생성 주체와 보존 정책을 점검합니다.
inode full파일 생성 실패df -i
진단 순서 시작 →서버 CPU 사용률이 계속 높을 때
로드 평균과 CPU 점유 프로세스를 구분하고 서비스 로그를 확인한 뒤 재시작 여부를 판단합니다.
CPU 100%load averagetop
진단 순서 시작 →메모리 부족과 OOM 종료를 확인할 때
가용 메모리, Swap, 프로세스 점유율과 커널 OOM 기록을 순서대로 확인합니다.
OOM killed메모리 부족swap
진단 순서 시작 →특정 포트를 누가 사용 중인지 찾을 때
LISTEN 소켓, PID, 실행 파일과 systemd 서비스를 연결해 포트 충돌 원인을 확인합니다.
포트 사용 프로세스Address already in usess
진단 순서 시작 →서비스가 시작되지 않거나 failed일 때
systemctl 상태, 현재 부팅 로그, 실제 unit 내용과 문법을 확인해 재시작 전에 원인을 찾습니다.
systemctl failed서비스 시작 실패journalctl
진단 순서 시작 →NGINX 502·504 오류를 진단할 때
프록시 자체, upstream 포트, 애플리케이션 응답과 타임아웃을 분리해 확인합니다.
502 Bad Gateway504 Gateway Timeoutnginx
진단 순서 시작 →서버에서 외부 통신이 되지 않을 때
인터페이스, 기본 경로, DNS, TCP 연결 순서로 네트워크 장애 구간을 나눕니다.
인터넷 연결 실패Network unreachableip route
진단 순서 시작 →DNS 조회가 실패하거나 느릴 때
현재 DNS 서버, 로컬 resolver, 지정 서버 조회를 비교해 이름 해석 문제를 좁힙니다.
DNS 실패Temporary failure in name resolutionresolvectl
진단 순서 시작 →SSL/TLS 인증서와 만료일을 확인할 때
SNI를 포함한 원격 인증서, 체인, 만료일과 로컬 파일을 비교해 인증서 장애를 진단합니다.
SSL 인증서certificate expiredopenssl s_client
진단 순서 시작 →Docker 컨테이너가 계속 재시작될 때
상태·종료 코드·OOM 여부·로그·리소스와 restart policy를 확인해 재시작 루프의 원인을 찾습니다.
Docker restarting컨테이너 재시작OOMKilled
진단 순서 시작 →Permission denied 원인을 찾을 때
대상 파일뿐 아니라 상위 디렉터리, 서비스 사용자, ACL과 실행 컨텍스트를 확인한 뒤 최소 권한만 수정합니다.
Permission deniedchmodchown
진단 순서 시작 →SSH 접속이 거부되거나 시간 초과될 때
클라이언트 오류, 서버 포트, ssh service·socket, 방화벽과 인증 로그를 분리해 원인을 좁힙니다.
SSH 접속 불가Connection timed outConnection refused
진단 순서 시작 →CPU는 낮은데 서버 응답이 느릴 때
load average를 CPU 사용률로 단정하지 않고 CPU·메모리·I/O pressure와 디스크 오류를 비교합니다.
load average highiowait서버 느림
진단 순서 시작 →파일시스템이 읽기 전용으로 바뀌었을 때
마운트 옵션, 커널 오류와 실제 블록 장치를 확인하고 운영 중 강제 remount 대신 오프라인 복구를 준비합니다.
Read-only file systemEXT4-fs errorI/O error
진단 순서 시작 →Docker 디스크와 컨테이너 로그가 커질 때
이미지·컨테이너·볼륨·빌드 캐시와 로그를 구분하고 데이터 소유자를 확인한 뒤 필요한 대상만 정리합니다.
Docker disk full/var/lib/dockerjson-file log
진단 순서 시작 →Docker 컨테이너 네트워크와 DNS가 실패할 때
호스트와 컨테이너의 네트워크 namespace, DNS 설정, 사용자 정의 네트워크와 포트 공개를 차례로 비교합니다.
Docker DNScontainer network127.0.0.11
진단 순서 시작 →NGINX에서 413 파일 업로드 오류가 날 때
413 응답을 만든 프록시 계층, client_max_body_size 적용 위치와 임시 저장공간을 확인한 뒤 필요한 범위만 조정합니다.
413 Request Entity Too Largeclient_max_body_sizeNGINX upload
진단 순서 시작 →서버 시간과 NTP 동기화가 맞지 않을 때
현재 시각·시간대와 동기화 공급자를 확인하고 timesyncd와 chrony를 혼용하지 않은 상태에서 NTP 연결을 복구합니다.
NTP synctimedatectlclock skew
진단 순서 시작 →AppArmor DENIED로 애플리케이션이 차단될 때
일반 파일 권한과 AppArmor 정책을 분리하고 DENIED 로그의 profile·operation·name을 해석해 최소 규칙만 반영합니다.
apparmor DENIEDaa-statusPermission denied
진단 순서 시작 →APT·DPKG 설치와 업데이트가 중단될 때
정상적인 단계적 업데이트와 실제 패키지 오류를 구분하고 잠금 소유자, 미구성 패키지와 의존성을 안전한 순서로 복구합니다.
apt errordpkg was interruptedheld broken packages
진단 순서 시작 →Ubuntu 부팅이 느리거나 systemd unit이 실패할 때
접속 가능한 시스템이나 복구 콘솔에서 부팅 시간을 분해하고 실패 unit, critical chain과 직전 부팅 로그를 확인합니다.
Ubuntu boot slowsystemd-analyze blamefailed unit
진단 순서 시작 →/etc/fstab 오류로 마운트가 실패할 때
재부팅으로 시험하지 않고 UUID, fstab 문법과 systemd mount unit을 검증한 뒤 승인된 마운트만 적용합니다.
fstab errormount failedDependency failed for Local File Systems
진단 순서 시작 →Too many open files 오류가 발생할 때
프로세스의 실제 파일 디스크립터 사용량과 soft·hard limit을 비교해 누수와 단순 제한 부족을 구분합니다.
Too many open filesEMFILELimitNOFILE
진단 순서 시작 →Cron·systemd timer 작업이 실행되지 않을 때
스케줄러 종류, 다음 실행 시각과 실제 service 결과를 구분하고 시간대·환경변수·권한·놓친 실행 처리 방식을 확인합니다.
cron not runningsystemd timer failedOnCalendar
진단 순서 시작 →NGINX 404·잘못된 사이트·리다이렉트 루프가 발생할 때
실제 Host와 listen 조합, server·location 선택과 root·try_files·rewrite 흐름을 활성 설정 기준으로 확인합니다.
nginx 404wrong server blockredirect loop
진단 순서 시작 →PostgreSQL 연결 수가 초과되거나 접속이 거부될 때
네트워크·인증 오류와 connection slot 부족을 구분하고 사용자·애플리케이션·상태별 연결과 장기 트랜잭션을 확인합니다.
remaining connection slots are reservedtoo many clients alreadymax_connections
진단 순서 시작 →PostgreSQL 장기 쿼리와 락 대기가 발생할 때
대기 세션과 blocking PID를 연결하고 락 종류·트랜잭션 나이·소유 작업을 확인한 뒤 취소와 종료를 단계적으로 판단합니다.
PostgreSQL lock waitpg_blocking_pidspg_locks
진단 순서 시작 →Kubernetes CrashLoopBackOff·OOMKilled·Probe 장애
반복 재시작을 이전 컨테이너 로그, 종료 이유, 리소스 제한, startup·liveness·readiness probe 순서로 분리해 원인에 맞는 최소 변경만 적용합니다.
CrashLoopBackOffOOMKilled exit 137liveness probe failed
진단 순서 시작 →Kubernetes ImagePullBackOff·ErrImagePull 장애
이미지 이름·태그·digest, 레지스트리 DNS·TLS·인증, imagePullSecret의 namespace와 ServiceAccount 연결을 구분해 비밀값을 노출하지 않고 복구합니다.
ImagePullBackOffErrImagePullFailed to pull image
진단 순서 시작 →Kubernetes Pending·PVC·Node NotReady 장애
Pending Pod의 scheduler 이벤트를 시작점으로 리소스·taint·affinity, PVC 바인딩, Node Ready·Pressure 상태를 분리하고 데이터 손실 없는 조치만 선택합니다.
Pod PendingFailedSchedulingunbound immediate PersistentVolumeClaims
진단 순서 시작 →Docker daemon·socket 권한 장애
Cannot connect와 permission denied를 daemon 중단, 잘못된 context·DOCKER_HOST, Unix socket 권한, rootless 모드로 나눠 과도한 chmod 없이 해결합니다.
Cannot connect to the Docker daemonpermission denied docker.sockIs the docker daemon running
진단 순서 시작 →Redis 연결·메모리·eviction 장애
Connection refused·timeout·NOAUTH와 OOM·evicted_keys를 분리하고 INFO·CONFIG GET으로 메모리 여유와 정책을 확인한 뒤 데이터 성격에 맞는 조치만 적용합니다.
Redis connection refusedRedis timeout NOAUTHOOM command not allowed
진단 순서 시작 →MySQL lock·deadlock·slow query 장애
잠금 대기, InnoDB deadlock, 느린 SQL을 performance_schema와 정규화된 digest로 구분하고 민감한 SQL 노출과 무분별한 세션 종료 없이 조치합니다.
MySQL lock wait timeoutDeadlock found when trying to get lockSHOW ENGINE INNODB STATUS
진단 순서 시작 →JVM OutOfMemoryError·OS OOM 장애
Java heap·Metaspace·direct/native memory와 Linux OOM kill을 구분하고 JVM flags, GC·class histogram, dump 공간과 민감도를 확인한 뒤 증거를 보존하며 최소 설정만 변경합니다.
Java heap spaceOutOfMemoryErrorMetaspace OOM
진단 순서 시작 →PM2 재시작 루프·errored 상태
PM2 restart count와 exit code, 애플리케이션 로그·cwd·Node 경로·의존성을 분리하고 watch·memory restart·startup PATH·backoff 설정을 검토해 반복 호출 없이 복구합니다.
PM2 restart loopPM2 erroredPM2 restart count
진단 순서 시작 →Kafka consumer lag·rebalance 장애
consumer group의 CURRENT-OFFSET·LOG-END-OFFSET·LAG·active member와 partition 편중, broker·application 처리율을 구분하고 offset reset의 중복·유실 위험을 차단하며 복구합니다.
Kafka consumer lagkafka-consumer-groupsconsumer group rebalance
진단 순서 시작 →OpenSearch red·unassigned shard 장애
cluster health에서 primary·replica unassigned를 구분하고 Allocation Explain의 disk·filter·awareness·same_shard·max_retry 결정을 확인해 강제 stale primary 없이 안전하게 재할당합니다.
OpenSearch red clusterunassigned shardscluster allocation explain
진단 순서 시작 →PostgreSQL 연결 고갈·느린 쿼리·락·복제 지연
SQL 원문이나 비밀번호를 노출하지 않고 연결 슬롯, wait event·blocking PID, query ID 통계와 WAL 위치를 같은 시각에 비교해 연결 고갈·느린 실행·락 경합·복제 지연을 구분합니다.
PostgreSQL too many clientsremaining connection slotsPostgres slow query
진단 순서 시작 →Kubernetes DNS·CoreDNS·Service 이름 해석 장애
영향 Pod의 resolv.conf와 ndots·dnsPolicy, namespace별 Service 이름, kube-dns Service·EndpointSlice·CoreDNS, NetworkPolicy의 UDP/TCP 53을 순서대로 확인해 DNS 장애 범위를 안전하게 분리합니다.
Kubernetes DNS failureCoreDNS SERVFAILkube-dns timeout
진단 순서 시작 →TLS 인증서 만료·체인·SNI·프로토콜 장애
curl -k로 우회하지 않고 UTC 시각, SAN·만료일, 검증 체인, SNI별 leaf 인증서와 TLS 1.2·1.3 협상 결과를 분리해 확인한 뒤 NGINX 설정과 인증서 갱신을 안전하게 적용합니다.
certificate expiredunable to get local issuer certificateTLS SNI wrong certificate
진단 순서 시작 →Linux 기본 명령어와 서버 정보 수집
배포판에 공통으로 사용할 수 있는 조회 명령으로 서버 식별, OS·Kernel, CPU·메모리·디스크, 네트워크와 주요 실행 서비스를 정리합니다.
리눅스 기본 명령어서버 정보 확인Linux system inventory
기본 명령어 보기 →Ubuntu 기본 명령어와 운영 상태 점검
Ubuntu 서버의 릴리스·패키지 상태, Netplan·DNS, UFW·AppArmor, 시간 동기화와 실패 서비스를 조회 전용 명령으로 확인합니다.
우분투 기본 명령어Ubuntu server checknetplan resolvectl
기본 명령어 보기 →