2시간 사용 후 루트 파티션이 가득 찼습니다.

2시간 사용 후 루트 파티션이 가득 찼습니다.

최근에 루트 파티션의 공간이 부족하다는 메시지를 받았기 때문에 파티션 크기를 9GB에서 30GB로 늘리기로 결정했습니다. (확실히 확인하기 위해) 앞으로는 바쁠 때 이 문제를 처리할 필요가 없습니다. 미래에. 아마 2시간 전에 이런 메시지를 받았는데 방금 또 이런 메시지가 왔어요? 내 루트 파티션이 이제 27GB로 가득 찬 것 같습니다. 내 루트 파티션에 프로그램이나 파일이 저장될 가능성이 있습니까?

다음은lsblk

NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda      8:0    0 931.5G  0 disk 
├─sda1   8:1    0   529M  0 part 
├─sda2   8:2    0   1.1G  0 part /boot/efi
├─sda3   8:3    0 540.3G  0 part 
├─sda4   8:4    0  29.1G  0 part /
└─sda5   8:5    0 360.5G  0 part /home

다음에 대한 출력du -h --max-depth 1 /var

4.0K    /var/mail
4.0K    /var/opt
18G     /var/lib
9.8M    /var/spool
55M     /var/crash
8.0K    /var/lock
90M     /var/cache
905M    /var/log
76K     /var/tmp
4.0K    /var/local
132K    /var/backups
19G     /var

업데이트:아주 최근에 oracle db를 실행하기 위해 docker를 설치했는데 이것이 원인일 수도 있습니다. ~ 안에이 스레드, 이 명령은 모든 컨테이너와 이미지를 제거하는 데 권장되며 13GB의 공간을 확보했습니다.

저는 실제로 Windows 파티션에 11g를 설치했기 때문에 이 컨테이너를 단지 놀기 위해 사용하고 있었습니다.

다음에 대한 출력du -x / | sort -n | tail -30

318900  /usr/share/libreoffice/help
326748  /usr/lib/libreoffice
332656  /usr/share/libreoffice
341964  /usr/share/fonts/opentype
412112  /usr/lib/jvm/java-11-openjdk-amd64
412124  /usr/lib/jvm
480108  /usr/share/fonts
491740  /usr/bin
668084  /usr/lib/firmware
922872  /var/log/journal/3699a9056d9109ba5307595660a9fe08
922876  /var/log/journal
937232  /var/log
956460  /var/lib/docker/volumes/98c155107c69aa57a69cc71514d4976fb484bb5a6467d6c6ae61ac67092b920e/_data/u02/app/oracle/oradata/ORCLCDB/orclpdb1
1081484 /usr/lib/x86_64-linux-gnu
1110068 /var/lib/docker/volumes/98c155107c69aa57a69cc71514d4976fb484bb5a6467d6c6ae61ac67092b920e/_data/u02/app/oracle/oradata/ORCLCDB/pdbseed
2668860 /usr/share
3526180 /usr/lib
3777544 /var/lib/docker/volumes/98c155107c69aa57a69cc71514d4976fb484bb5a6467d6c6ae61ac67092b920e/_data/u02/app/oracle/oradata/ORCLCDB
3777548 /var/lib/docker/volumes/98c155107c69aa57a69cc71514d4976fb484bb5a6467d6c6ae61ac67092b920e/_data/u02/app/oracle/oradata
3778008 /var/lib/docker/volumes/98c155107c69aa57a69cc71514d4976fb484bb5a6467d6c6ae61ac67092b920e/_data/u02/app/oracle
3778012 /var/lib/docker/volumes/98c155107c69aa57a69cc71514d4976fb484bb5a6467d6c6ae61ac67092b920e/_data/u02/app
3778016 /var/lib/docker/volumes/98c155107c69aa57a69cc71514d4976fb484bb5a6467d6c6ae61ac67092b920e/_data/u02
3814936 /var/lib/docker/volumes/98c155107c69aa57a69cc71514d4976fb484bb5a6467d6c6ae61ac67092b920e/_data
3814940 /var/lib/docker/volumes/98c155107c69aa57a69cc71514d4976fb484bb5a6467d6c6ae61ac67092b920e
3814968 /var/lib/docker/volumes
3815324 /var/lib/docker
4250432 /var/lib
5428724 /var
7058496 /usr
12854996    /

답변1

살펴볼 기본 디렉토리는 일반 응용 프로그램에서 쓸 수 있는 모든 항목을 위한 /var입니다. /run 및 /tmp도 있지만 이는 많은 배포판에서 RAM 디스크인 경우가 많습니다.

당신이 사용할 수있는

df --max-depth 1 /var

어느 것을 조사하기 위해. 하지 마라그것이 무엇인지 알기도 전에 삭제하세요.

귀하가 설명하는 것처럼 시스템이 스토리지를 완전히 소진하는 경우 로그 파일을 작성하는 동안 무언가 회전이 멈추어 발생하는 경우가 많으며 로그 파일은 몇 GB에 달할 수 있습니다. 따라서 /var/log일 가능성이 높습니다.

때로는 /var/cache /var/tmp 또는 /var/lib에 쓰기가 중단된 프로세스로 인해 발생할 수도 있습니다.

관련 정보