☰

2時間の使用後、ルートパーティションがいっぱいになる

tag-icon • tag-icon ubuntu partition storage root-filesystem pop-os
2時間の使用後、ルートパーティションがいっぱいになる

最近、ルート パーティションの空き容量が少なくなっているというメッセージを受け取りました。そのため、パーティションのサイズを 9 GB から 30 GB に増やすことにしました (念のため)。そうすれば、今後、忙しいときにこの問題に対処しなくて済みます。おそらく 2 時間前にこれを行ったのですが、このメッセージが再び表示されました。ルート パーティションが 27 GB でいっぱいになっているようですが、プログラムやファイルがルート パーティションに保存されている可能性はありますか?

出力は次のようになります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をインストールしたので、これが原因かもしれないと思いました。このスレッドこのコマンドはすべてのコンテナとイメージを削除する場合に推奨され、13 GB のスペースが解放されました。

私は実際に 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 への書き込み中にプロセスがおかしくなることで発生することもあります。

関連情報