![루트 "/" 디렉터리가 100% 소비되고 시스템이 재부팅됩니다. 재부팅 후 사용량이 75%로 떨어지므로 근본 원인을 찾아야 합니다. [닫기]](https://linux55.com/image/161506/%EB%A3%A8%ED%8A%B8%20%22%2F%22%20%EB%94%94%EB%A0%89%ED%84%B0%EB%A6%AC%EA%B0%80%20100%25%20%EC%86%8C%EB%B9%84%EB%90%98%EA%B3%A0%20%EC%8B%9C%EC%8A%A4%ED%85%9C%EC%9D%B4%20%EC%9E%AC%EB%B6%80%ED%8C%85%EB%90%A9%EB%8B%88%EB%8B%A4.%20%EC%9E%AC%EB%B6%80%ED%8C%85%20%ED%9B%84%20%EC%82%AC%EC%9A%A9%EB%9F%89%EC%9D%B4%2075%25%EB%A1%9C%20%EB%96%A8%EC%96%B4%EC%A7%80%EB%AF%80%EB%A1%9C%20%EA%B7%BC%EB%B3%B8%20%EC%9B%90%EC%9D%B8%EC%9D%84%20%EC%B0%BE%EC%95%84%EC%95%BC%20%ED%95%A9%EB%8B%88%EB%8B%A4.%20%5B%EB%8B%AB%EA%B8%B0%5D.png)
다음 오류가 발생한 후 시스템을 재부팅했는데, 재부팅 후 사용량이 75%로 떨어지는 문제가 발생했습니다.
dfmon[16139]: FATAL: 디스크 사용 가능 모니터: 102 #파일 시스템 "/"가 100% 가득 찼습니다.
로그나 다른 곳에서 이 공간을 차지하는 파일을 찾을 수 있는 방법이 있습니까? 어떤 프로세스에서 이러한 파일이 생성될 수 있으며 문제를 해결해야 할 수도 있습니다.
어떤 도움이라도 대단히 감사하겠습니다.
답변1
/tmp 또는 시작 시 비워졌을 수 있는 기타 디렉터리에 의심스러울 정도로 큰 파일이 표시되지 않으면 파일이 연결되지 않았지만 여전히 열려 있기 때문일 수 있습니다.
이는 일반적으로 다른 프로세스에 전달될 수 있지만 관련되지 않은 프로세스에서 파일 이름으로 액세스하는 공유 메모리를 생성하는 등 일부 프로그램에 의해 의도적으로 발생합니다. 예를 들어 로그 파일이 회전/삭제되었지만 로깅 프로세스에서 파일을 열어 둔 경우에도 이런 일이 실수로 발생할 수 있습니다.
예를 들어 , 파일을 열어 둔 모든 프로세스가 종료되거나(늦어도 시스템이 완전히 종료될 때) fsck
정전 후 실행될 때 이러한 파일은 더 이상 존재하지 않습니다. 따라서 이러한 파일은 재부팅 후 사용량 감소를 설명할 수 있습니다.
삭제되었지만 마운트 지점에 생성된 아직 열려 있는 모든 파일을 보려면 루트로 다음을 시도하십시오 /
.
lsof -s -- / | grep -e '^COMMAND \| (deleted)' | less
이 열에는 COMMAND
파일을 열어 둔 프로세스의 이름, SIZE
파일 크기(바이트), NAME
파일이 삭제되기 전의 원래 경로가 포함됩니다.
목록에 매우 큰 파일이나 일반적인 로그 파일 이름이 표시되면 범인을 찾은 것일 수 있습니다.
답변2
다음을 시도해 보세요. 드라이브가 꽉 차서 시간이 걸릴 수 있습니다. 루트 디렉터리 아래의 모든 파일을 확인한 다음 크기별로 정렬합니다.
du / | sort -n
시간이 오래 걸리면 요약을 받아 자세히 알아볼 수 있을 때까지 반복하세요.
du -s /* | sort -n
답변3
패키지 관리자에는 일반적으로 약간의 공간이 필요한 캐시가 있습니다. sudo yum clean all
아니면 sudo apt-get clean all
뭔가를 청소할 수도 있습니다.
du
훌륭한 도구입니다. 나는 사용할 것이다du -xhd1 /
-x, --one-file-system -h, --human-readable -d, --max-depth=N
하지만 물건을 삭제하는 데 열중하지 마십시오. 귀하의 서버 애플리케이션이 데이터를 쓰는 위치를 찾아 해당 로그가 손에 잡히지 않는지 확인합니다.