Root-Partition nach 2 Stunden Nutzung voll

Root-Partition nach 2 Stunden Nutzung voll

Ich habe vor Kurzem eine Nachricht erhalten, dass der Speicherplatz in meiner Root-Partition knapp wird. Daher habe ich beschlossen, die Größe meiner Partition von 9 GB auf 30 GB zu erhöhen (nur um sicherzugehen), damit ich mich in Zukunft nicht mehr damit befassen muss, wenn ich beschäftigt bin. Ich habe das vor vielleicht 2 Stunden getan, aber gerade diese Nachricht erneut erhalten. Es scheint, als ob meine Root-Partition jetzt 27 GB voll ist. Besteht die Möglichkeit, dass Programme oder Dateien in meiner Root-Partition gespeichert werden?

Hier ist die Ausgabe vonlsblk

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

Ausgabe fürdu -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

Aktualisieren:Ich habe vor kurzem Docker installiert, um Oracle DB auszuführen, also dachte ich, das könnte eine Ursache sein.dieser Thread, dieser Befehl wird zum Entfernen aller Container und Bilder empfohlen und ich habe 13 GB Speicherplatz freigegeben.

Ich habe diesen Container nur zum Herumspielen verwendet, da ich tatsächlich 11g in meiner Windows-Partition installiert habe.

Ausgabe fürdu -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    /

Antwort1

Das wichtigste Verzeichnis, das Sie sich ansehen sollten, ist /var. Es ist für alles vorgesehen, was von normalen Anwendungen beschrieben werden kann. Es gibt auch /run und /tmp, aber bei vielen Distributionen handelt es sich dabei oft um eine RAM-Disk.

Sie können

df --max-depth 1 /var

um zu untersuchen, welches. nichtlöschen Sie Dinge, bevor Sie wissen, was sie sind.

Wenn Systeme ihren Speicher wie von Ihnen beschrieben leeren, liegt das häufig daran, dass etwas beim Schreiben einer Protokolldatei hängen bleibt. Die Protokolldatei kann mehrere GB groß sein. Daher ist /var/log ziemlich wahrscheinlich.

Gelegentlich kann es auch durch einen verrücktspielenden Prozess verursacht werden, der in /var/cache, /var/tmp oder /var/lib schreibt.

verwandte Informationen