ftomasch
Anmeldungsdatum: 11. Februar 2020
Beiträge: 131
|
Hallo!
Seit einige Zeit ereignen sich seltsame Dinge:
In der / (root)-Partition haben sich innerhalb der letzten 1 1/2 Tage so viele Daten angesammelt, dass gar kein freier Platz mehr vorhanden ist. Dieses Phänomän hatte ich vor einer Woche schon einmal. Da habe ich noch gedacht, dass die Partitition zu klein sei. Ich habe sie von 100 GiB auf 150 GiB erweitert und Kubuntu komplett neu aufgesetzt.
Ich habe zusätzlich ein Plasmoid installiert, was den belegten Speicherplatz von "/(root)" anzeigt. Gestern morgen war die Festplatte noch mit 30 GiB belegt.
Heute kam eine halbe Stunde nachdem ich den Rechner hochgefahren hatte, die Benachrichtigung, dass der Speicherplatz unter der Root-Partition restlos aufgebraucht ist.
Der Speicherplatz auf den anderen drei Partitionen ist unverändert geblieben Ich binn völlig ratlos! Was kann die Ursache dafür sein?
Und wie kann ich feststellen, um was für Daten es sich dabei handelt?
Da auf der Root kein Platz mehr ist,stelle ich mir das schwierig vor
Ist es sinnvoll von einem Livesystem via USB-Stick die "Root" zu inspizieren?
Und mit welchen Programm? Oder geht das auch über die Konsole? Moderiert von Thomas_Do: Thema in einen passenden Forenbereich verschoben. Bitte beachte die als wichtig markierten Themen („Welche Themen gehören hier her und welche nicht?“) in jedem Forenbereich. Danke. Bearbeitet von Thomas_Do: Titel an Problem angepasst.
|
Thomas_Do
Moderator
Anmeldungsdatum: 24. November 2009
Beiträge: 8808
|
Ist es "Home" oder "Root", das vollläuft? Du musst erst einmal herausfinden, um welche Dateien es sich handelt. Könnten z. B. „überlaufende“ Logdateien sein, weil ein Programm fehlerhaft arbeitet. Im Wiki findest Du dazu Hilfestellung. Für die Hilfe hier eignet sich ein Terminalbefehl am besten. Eine erste Übersicht gibt:
sudo du -shx /* | sort -h Den Befehl im Terminal eingeben und die vollständige Ein- und Ausgabe hier als Codeblock posten. Dazu den Text einfach in drei geschweifte Klammern einschließen: {{{ Text Text Text }}}.
|
Kreuzschnabel
Anmeldungsdatum: 12. Dezember 2011
Beiträge: 1351
|
Ich weiß jetzt nicht, was du alles zusätzlich installiert hast, aber eine Grundinstallation von Kubuntu sollte etwa 12 GB belegen. Mit 25 bis 30 GB ist eine root-Partition eigentlich schon großzügig bemessen, mehr muss wirklich nur in Ausnahmefällen, wenn ein Videoeditor unter /tmp riesige Datenmengen ablegt oder so. Ich hatte mal in einem Lenovo-Laptop den Effekt, dass /var/log mit Fehlermeldungen zulief. Schau dir mal da die syslog und die kern.log an. Wenn die riesig sind (normal sind das einige -zig MB), kannst du sie für eine schnelle Lösung einfach (als root) löschen und dann neu booten. Substanzieller wäre es, vorher zu schauen, welche Meldungen die so aufblasen – große Logfiles sind ja nicht die Ursache, sondern das Symptom, und solange der auslösende Fehler besteht, wird dein System nicht zuverlässig laufen. Bei mir war es ein Fehler in der NVMe-Schnittstelle. Hardware gewechselt, nie wieder passiert. --ks PS: Meinst du im Titel home oder root?
|
tomtomtom
Supporter
Anmeldungsdatum: 22. August 2008
Beiträge: 55209
Wohnort: Berlin
|
Kreuzschnabel schrieb: PS: Meinst du im Titel home oder root?
Oder gar /root , dann würde ja auch Home wieder irgendwie stimmen. ☺
|
ftomasch
(Themenstarter)
Anmeldungsdatum: 11. Februar 2020
Beiträge: 131
|
Hallo Thomas!
Ok, hier kommt die Übersicht:
0 /bin
0 /boot
3,7G /cdrom
0 /dev
0 /etc
0 /home
0 /lib
0 /lib64
0 /media
0 /mnt
0 /opt
du: cannot access '/proc/5061/task/5061/fd/4': No such file or directory
du: cannot access '/proc/5061/task/5061/fdinfo/4': No such file or directory
du: cannot access '/proc/5061/fd/3': No such file or directory
du: cannot access '/proc/5061/fdinfo/3': No such file or directory
0 /proc
5,6G /rofs
0 /root
9,7M /run
0 /sbin
0 /snap
0 /srv
0 /sys
4,0K /tmp
0 /usr
0 /var .
Diese Übersicht konnte ich nur noch über das Kubuntu-Livesystem erstellen, da das "normale" hochfahren schon nicht mehr funktionierte. Hallo Kreuzschnabel!
Viedeoschnitt mache ich nicht, mein Schwerpunkt liegt in der Bildbearbeitung und im Digital Painting. Daher sind meine wichtigsten Programme digiKam, Darktable und Krita.
Die Datenbank von DigiKam habe ich auf aus dem System ausgelagert und auf einer "reinen Datenpartition) untergebrach.
Kubuntu (und damit auch Linux) sind für mich neu und fasziniernend. Daher bin ich auch dabei, die neuen Möglichkeiten zu entdecken, wie den Browser Wavebox oder raindrop....
Und damit lag ich im Dateneverbrauch in dem Rahmen, den Du angegeben hast. Die Festplatte mit der Systempartition und einer weiteren "Datenpartition" sind über die NVMe Schnittstelle eingebunden ...
|
tomtomtom
Supporter
Anmeldungsdatum: 22. August 2008
Beiträge: 55209
Wohnort: Berlin
|
ftomasch schrieb: Diese Übersicht konnte ich nur noch über das Kubuntu-Livesystem erstellen, da das "normale" hochfahren schon nicht mehr funktionierte.
Heißt auf deutsch, dass sie nicht verwertbar ist, weil du das Livesystem analysiert hast. Denke ich mal, denn da du ja nur einen Ausschnitt und nicht den genutzten Befehl zeigst, kann das niemand genau wissen. Für das installierte System musst du das schon einhängen und den Pfad für den Befehl entsprechend anpassen, wenn du das von einem Livesystem aus machst.
|
ftomasch
(Themenstarter)
Anmeldungsdatum: 11. Februar 2020
Beiträge: 131
|
OK, ich hoffe, das das jestzt der richtige Pfad ist:
kubuntu@kubuntu:/media/kubuntu/bd7176cc-0acb-406f-b62b-83f570a8a97f$ dir
bin cdrom etc lib lost+found mnt proc run snap sys usr
boot dev home lib64 media opt root sbin srv tmp var
kubuntu@kubuntu:/media/kubuntu/bd7176cc-0acb-406f-b62b-83f570a8a97f$ sudo du -shx /* | sort -h
du: cannot access '/proc/5132/task/5132/fd/4': No such file or directory
du: cannot access '/proc/5132/task/5132/fdinfo/4': No such file or directory
du: cannot access '/proc/5132/fd/3': No such file or directory
du: cannot access '/proc/5132/fdinfo/3': No such file or directory
0 /bin
0 /boot
0 /dev
0 /etc
0 /home
0 /lib
0 /lib64
0 /media
0 /mnt
0 /opt
0 /proc
0 /root
0 /sbin
0 /snap
0 /srv
0 /sys
0 /usr
0 /var
4,0K /tmp
9,7M /run
3,7G /cdrom
5,6G /rofs
|
tomtomtom
Supporter
Anmeldungsdatum: 22. August 2008
Beiträge: 55209
Wohnort: Berlin
|
ftomasch schrieb: OK, ich hoffe, das das jestzt der richtige Pfad ist:
kubuntu@kubuntu:/media/kubuntu/bd7176cc-0acb-406f-b62b-83f570a8a97f$ dir
bin cdrom etc lib lost+found mnt proc run snap sys usr
boot dev home lib64 media opt root sbin srv tmp var
kubuntu@kubuntu:/media/kubuntu/bd7176cc-0acb-406f-b62b-83f570a8a97f$ sudo du -shx /* | sort -h
Solange du als Pfad / angibst zeigt du auch die darunter liegenden Verzeichnisse an, also weiterhin das Livesystem... Ich würde den aber sowieso etwas abwandeln, versuche mal ein sudo du -h --max-depth=1 /media/kubuntu/bd7176cc-0acb-406f-b62b-83f570a8a97f | sort -h
|
ftomasch
(Themenstarter)
Anmeldungsdatum: 11. Februar 2020
Beiträge: 131
|
Ah! Das sieht jetzt ganz aus!:
kubuntu@kubuntu:~$ sudo du -h --max-depth=1 /media/kubuntu/bd7176cc-0acb-406f-b62b-83f570a8a97f | sort -h
4,0K /media/kubuntu/bd7176cc-0acb-406f-b62b-83f570a8a97f/cdrom
4,0K /media/kubuntu/bd7176cc-0acb-406f-b62b-83f570a8a97f/mnt
4,0K /media/kubuntu/bd7176cc-0acb-406f-b62b-83f570a8a97f/opt
4,0K /media/kubuntu/bd7176cc-0acb-406f-b62b-83f570a8a97f/proc
4,0K /media/kubuntu/bd7176cc-0acb-406f-b62b-83f570a8a97f/srv
4,0K /media/kubuntu/bd7176cc-0acb-406f-b62b-83f570a8a97f/sys
12K /media/kubuntu/bd7176cc-0acb-406f-b62b-83f570a8a97f/dev
16K /media/kubuntu/bd7176cc-0acb-406f-b62b-83f570a8a97f/lost+found
48K /media/kubuntu/bd7176cc-0acb-406f-b62b-83f570a8a97f/tmp
96K /media/kubuntu/bd7176cc-0acb-406f-b62b-83f570a8a97f/snap
144K /media/kubuntu/bd7176cc-0acb-406f-b62b-83f570a8a97f/run
15M /media/kubuntu/bd7176cc-0acb-406f-b62b-83f570a8a97f/etc
47M /media/kubuntu/bd7176cc-0acb-406f-b62b-83f570a8a97f/root
245M /media/kubuntu/bd7176cc-0acb-406f-b62b-83f570a8a97f/boot
3,0G /media/kubuntu/bd7176cc-0acb-406f-b62b-83f570a8a97f/home
7,7G /media/kubuntu/bd7176cc-0acb-406f-b62b-83f570a8a97f/usr
13G /media/kubuntu/bd7176cc-0acb-406f-b62b-83f570a8a97f/var
119G /media/kubuntu/bd7176cc-0acb-406f-b62b-83f570a8a97f/media
142G /media/kubuntu/bd7176cc-0acb-406f-b62b-83f570a8a97f
kubuntu@kubuntu:~$
Müsste media nicht ganz leer sein?
|
Kreuzschnabel
Anmeldungsdatum: 12. Dezember 2011
Beiträge: 1351
|
ftomasch schrieb:
Müsste media nicht ganz leer sein?
So ziemlich, wenn nichts gemountet ist. Hast du da mal was auf eine Ressource schreiben wollen, die gar nicht gemountet war? Dann landets im physischen Verzeichnis. Jedenfalls kannst du jetzt mit ls -la /media/kubuntu/bd7176cc-0acb-406f-b62b-83f570a8a97f/media mal gucken, was da so drauf ist. --ks
|
tomtomtom
Supporter
Anmeldungsdatum: 22. August 2008
Beiträge: 55209
Wohnort: Berlin
|
Kreuzschnabel schrieb: So ziemlich, wenn nichts gemountet ist.
Da es sich ja um das von einem Livesystem eingebundene installierte System handelt (und somit auch dessen fstab nicht beachtet wird) sollte da nicht nur so ziemlich, sondern gar nichts liegen. 😉
|
ftomasch
(Themenstarter)
Anmeldungsdatum: 11. Februar 2020
Beiträge: 131
|
YES!!!
Das war es! –> da war ich zu voreilig
Im Detail:
Ich hatte ein Backup mit dem Programm "Backintime" durchgeführt.
In den Optionen des Programmes habe ich ausgewählt, dass bei Fehlern das Programm automatisch anhält.
Dies ist nicht erfolgt.
BiT hatte die Verbindung zur Sicherungsfestplatte verloren.
Statt anzuhalten hat das Programm das Backup weitergeführt und die Daten in /media/xxl geschrieben Vielen Dank für die Infos und die Unterstützung!
Im Nachhinein kann ich sagen, dass Linux wesentlich klarer strukturiert ist, als andere Betriebssysteme.
|
ftomasch
(Themenstarter)
Anmeldungsdatum: 11. Februar 2020
Beiträge: 131
|
Ohje, nachdem ich die betreffenden Ordner in Media/landsby gelöscht habe, war der belegte Speicherplatz wieder im Normalbereich, etwas über 25GiB.
Ich konnte den PC normal starten.
Alles lief perfekt, so wie vorher. Dann habe ich die Filesysteme sämtlicher Partitionen überprüft. Alles war ok. Sämtliche Partitionen sind gemounted.
Ein Backup müsste eigendlich fehlerfrei laufen.
Back in time habe ich gestartet und den Schnappschusss fortgesetzt. Dieser lief -zunächst- fehlerfrei. Nach einiger Zeit konnte ich sehen, dass der Speicherplatz der root immer kleiner wurde.
Nach dem Beenden von BiT verringerte sich der Speicherplatz immer noch.
Erst durch einen Neustart konnte ich dies stoppen. Nun sind knapp 54% von 146 GiB belegt. Unter /media/landsby befindet sich, beim zweiten hinschauen, ein Ordner "Backup". Diesen habe ich gelöscht. Also liegt der Fehler beim Programm Back in time?
|
Kreuzschnabel
Anmeldungsdatum: 12. Dezember 2011
Beiträge: 1351
|
ftomasch schrieb:
Ich hatte ein Backup mit dem Programm "Backintime" durchgeführt.
In den Optionen des Programmes habe ich ausgewählt, dass bei Fehlern das Programm automatisch anhält.
Dies ist nicht erfolgt.
BiT hatte die Verbindung zur Sicherungsfestplatte verloren.
Statt anzuhalten hat das Programm das Backup weitergeführt und die Daten in /media/xxl geschrieben
Eine gemountete Ressource „überdeckt“ den Knoten im Dateisystem, in den sie gemountet ist. Wenn du die Ressource /dev/sda2 (Beispiel) auf /media/xxl mountest, wird beim Schreiben auf /media/xxl tatsächlich auf /dev/sda2 geschrieben (genauer: auf das Dateisystem in /dev/sda2, das ist nicht dasselbe, direkt auf /dev/sda2 kannst du keine Dateien ablegen). Wenn du die Ressource wieder entfernst, wird auf den physischen Ordner /media/xxl in der root-Partition geschrieben, der ist dann „da“. BiT kann nicht erkennen, ob da was gemountet ist oder nicht. Wenn nicht, wird der Ordner halt angelegt (wobei BiT speziell schon seine Ordnerstruktur mit backintime/rechner/user/1/ erwartet).
Sämtliche Partitionen sind gemounted. Ein Backup müsste eigendlich fehlerfrei laufen. Back in time habe ich gestartet und den Schnappschusss fortgesetzt. Dieser lief -zunächst- fehlerfrei. Nach einiger Zeit konnte ich sehen, dass der Speicherplatz der root immer kleiner wurde. Nach dem Beenden von BiT
damit beendest du nur die Oberfläche. Die gestarteten rsync-Prozesse laufen weiter. Die kannst du in der Prozessverwaltung (Strg-Esc) killen.
verringerte sich der Speicherplatz immer noch. Erst durch einen Neustart konnte ich dies stoppen. Nun sind knapp 54% von 146 GiB belegt. Unter /media/landsby befindet sich, beim zweiten hinschauen, ein Ordner "Backup". Diesen habe ich gelöscht. Also liegt der Fehler beim Programm Back in time?
Also bei mir läuft BiT tadellos ☺ Überprüf erstmal deine Mountpunkte. Zum Beispiel müssen sich Windows-Umsteiger erst dran gewöhnen, dass Linux im Dateisystem zwischen Groß- und Kleinschreibung unterscheidet. Wenn du z.B. deine Backup-Ressource auf /media/backup mountest und BiT sagst, es soll auf /media/Backup backuppen, dann landet das nicht auf der Ressource, denn die ist auf backup gemountet und nicht auf Backup. Häufiger Fehler. Dass BiT mittendrin sein Backupziel switcht, kann ich mir nicht so recht vorstellen.
Im Nachhinein kann ich sagen, dass Linux wesentlich klarer strukturiert ist, als andere Betriebssysteme.
Das ist die Idee dahinter, ja ☺ --ks
|