대용량 로그 파일 삭제 후에도 디스크 공간이 꽉 차 보일 수 있는 이유

(dev.to)

리눅스 서버에서 대용량 로그 파일을 삭제했음에도 디스크 공간이 확보되지 않는 현상은 프로세스가 해당 파일을 여전히 점유하고 있기 때문이며, 이를 해결하기 위해서는 파일 이름 삭제가 아닌 프로세스의 파일 디스크립터 해제가 필요하다는 기술적 원인과 해결책을 설명합니다.

이 글의 핵심 포인트

1파일 삭제 시 디렉토리 엔트리는 제거되지만, 프로세스가 파일을 열고 있으면 데이터는 해제되지 않음
2du 명령어는 경로를 통해 파일을 찾으므로 삭제된 파일을 인식하지 못하지만, df는 할당된 블록을 보고하므로 불일치 발생
3lsof +L1 명령어를 통해 링크 카운트가 1 미만인, 즉 삭제되었으나 점유 중인 파일을 식별할 수 있음
4가장 안전한 해결책은 해당 프로세스를 재시작하거나 로그를 다시 열도록(reopen) 요청하는 것임
5proc 파일 시스템을 통한 트렁케이트는 긴급 처방으로 사용 가능하나, 애플리케이션의 버퍼나 오프셋에 영향을 줄 수 있음

이 글에 대한 공공지능 분석

왜 중요한가?

서버 운영 중 발생하는 갑작스러운 디스크 풀(Full) 장애는 서비스 중단의 직접적인 원인이 됩니다. 단순 파일 삭제로 해결되지 않는 이 현상의 메커니즘을 이해하는 것은 장애 복구 시간(MTTR)을 단축하는 데 필수적입니다.

어떤 배경과 맥락이 있나?

리눅스 파일 시스템은 파일 이름(Directory Entry)과 실제 데이터(Inode)를 분리하여 관리합니다. 프로세스가 파일을 열고 있는 동안에는 데이터가 삭제되지 않도록 설계되어 있어, 파일 이름이 사라져도 데이터는 프로세스가 종료될 때까지 유지됩니다.

업계에 어떤 영향을 주나?

로그 관리 미흡으로 인한 인프라 장애는 클라우드 비용 증가와 서비스 가용성 저하를 초래합니다. 특히 컨테이너 기반 환경에서 로그 로테이션(Log Rotation) 설정 오류는 대규모 서비스 중단으로 이어질 수 있는 잠재적 위험 요소입니다.

한국 시장에 어떤 시사점이 있나?

빠른 성장을 지향하며 인프라 확장이 빈번한 한국 스타트업들은 단순한 리소스 삭제를 넘어, 프로세스의 생명주기와 파일 디스크립터 상태를 고려한 정교한 모니터링 및 운영 자동화 체계를 구축해야 합니다.

이 글에 대한 큐레이터 의견

인프라 운영의 핵심은 '보이는 것이 전부가 아니다'라는 점을 인지하는 것입니다. 많은 개발자가 `rm` 명령어로 파일을 지우면 끝이라고 생각하지만, 실제 시스템 리소스는 프로세스의 상태에 종속되어 있습니다. 이는 단순한 기술적 지식을 넘어, 시스템의 동작 원리를 깊이 이해하지 못한 운영이 얼마나 치명적인 장애를 초래할 수 있는지를 보여주는 사례입니다.

물론, 프로세스를 재시작하는 것은 가장 확실한 해결책이지만, 트래픽이 몰리는 피크 타임에는 서비스 가용성을 해칠 수 있는 리스크가 있습니다. 따라서 로그 로테이션 설정을 정교화하거나, `lsof`를 통한 정기적인 점검 프로세스를 구축하는 것이 중요합니다. 급하게 `/proc`을 통한 트렁케이트(Truncate) 방식을 사용하는 것은 임시방편일 뿐, 애플리케이션의 버퍼나 오프셋에 영향을 줄 수 있으므로 매우 주의 깊은 접근이 필요합니다.

원문 보기 →