[Gelöst] Root Partition voll... Meldung "Low Disk Space".

Juan_Lutz · 13 Apr. 2017

Hallo,
Ich möchte folgende Partition-Status meinem System mitteilen und Vorschlag bei Euch holen:

Code:

linux-z76n:~ # df -h
Filesystem Size Used Avail Use% Mounted on
devtmpfs 3.9G 0 3.9G 0% /dev
tmpfs        3.9G 0 3.9G 0% /dev/shm
tmpfs        3.9G 2.4M 3.9G 1% /run
tmpfs        3.9G 0 3.9G 0% /sys/fs/cgroup
/dev/sda2   20G 20G 0 100% /
/dev/sda3 896G 368G 527G 42% /home
tmpfs        790M 0 790M 0% /run/user/481
tmpfs        790M 8.0K 790M 1% /run/user/0
linux-z76n:~ #

System: OS Leap 42.2 / KDE Plasma 5 – 5.9.4
File System benutzt bei allen Partitionen ist: ext4.

Das System läuft bis gestern OK. !!!
Heute wegen root „/“ Partition voll, startet das System nicht mehr…. Außer unter root aber mit der Meldung „Low Disk Space“.

Beim Nachschauen in verschiedenem Forum bin ich auf mögliche Lösungen getroffen:

1. Partitioniertes System „retten“ (https://linux-club.de/forum/viewtopic.php?f=90&t=121466&hilit=root+partition+voll)
2. Oder einfach das System neu Installieren.

Fragen: :???:
• Warum bin ich auf diese Situation gestoßen? Ich arbeite mit Linux ( Suse und später Opensuse ) schon sehr lange her..... und bin ich auf diese unangenehmen Verhalten meine Daten nie getroffen.
• Welche Maßnahmen oder Einstellungen soll ich berücksichtigen um diese Situation: „Root Partition voll“ vermeiden zu können.?
• Die Lösung: das partitioniertes System zu „retten“ (punkt 1 oben), scheint mir möglich aber ich vermute meine Partitionierung ist für ext4 nicht optimal. Abgesehen davon das die ganze Aktion laut die Rückmeldung im Forum satt 2 std. gebraucht hat. Die Vorbereitung z.B. Backup zu machen usw… entspricht der gleiche Aufwand wie eine „neue“ Installation.
• Wenn ich aber das System neu installiere, was wäre besser/sicherer/stabiler …. alle Partitionen mit Btrfs einzustellen, … oder alle ext4 mit einem neuen „Size“ für die Root Partition ( also >20G) … oder nur das root Partition mit Btrfs und Home mit ext4 ….?

Für Hinweise bedanke ich mich im Voraus.

J.-L.

josef-wien · 13 Apr. 2017

Da Du btrfs nicht verwendest, sind 20 GB für die Systempartition mehr als ausreichend (meine ist 16 GB groß und gerade zur Hälfte gefüllt). Mit

Code:

du -xh / | grep [0-9][.,]*[0-9]G | sort -n
find / -xdev -type f -size +1G -printf "%k\t%p\\n" | sort -g

(als root ausgeführt) findest Du große Verzeichnisse und Dateien. Mein erster Verdacht geht auf ein übergelaufenes (weil nie bereinigtes) Verzeichnis /tmp. Falls das der Fall ist, kannst Du den Inhalt löschen und dann dafür sorgen, daß das in Zukunft nicht mehr passiert: https://linux-club.de/wiki/opensuse/Tipp:_systemd-tmpfiles

Juan_Lutz · 13 Apr. 2017

Danke josef-wien.
deine Vermutung ist auch meine.
Danke für das Link.... ( war für mich bekannt und ich habe sie lange her ... angewendet !!!!) so wie ich verstanden habe: nach 2 Tage bzw. 7 bereinigen sich diese tmp Files beim Start der Maschine alleine .... dann ... was habe ich gestern getan, vermutlich um die tmp Verzeichnisse voll zu stopfen?. KDE - Updates, Internet, Spiele ... :irre:

Wenn Mein System so belastet wird ( mit allen Updates/multimedia/internet Kram ), könnte bedeuten das es mindestens 2 tage Lahm bleiben kann?.
Danke für die Vorgeschlagene CODES ...... jetzt bin ich unterwegs.... Feedback nächste Woche.
Aber da ich nur als root mich einloggen kann und wegen der Meldung "Low Disk Space" nur noch begrenzte Anwendungen zur Verfügung habe (i.e. dolphin startet nicht), Konsole, YaST, und Browser aber doch !...... Hier noch eine zusätzliche Frage:

Bezüglich dein Link: ... Anstatt jeder 2 Tage bzw. 7 wie kann ich diese Bereinigung beim jedem Start des System durchführen zu lassen?. Früher beim OS 13.2 gab es im YaST (etc/config... glaube ich) ein Befehl um tmp dateien beim start löschen zu können. im OS Leap 42.2 ist es nicht mehr da... und ...

Grüße,
J.-L.

gehrke · 13 Apr. 2017

Ich schlage vor, Du schaust erst mal beispielsweise mit Hilfe der von josef-wien vorgeschlagenen Kommandos nach, wo der Speicher tatsächlich hin geht. Dann müssen wir/Du nicht raten oder vermuten...

Juan_Lutz · 19 Apr. 2017

Hallo Alle miteinander !,
hier die entsprechende "output" von den vorgeschlagenen Kommandos (siehe oben der Beitrag von Josef-Wien):

Code:

# du -xh / | grep [0-9][.,]*[0-9]G | sort -n
2.2G    /usr/src
3.2G    /usr/lib64
4.0G    /usr/share
5.1G    /var/lib/systemd
5.1G    /var/lib/systemd/coredump
5.3G    /var/lib
6.6G    /var
8.0K    /root/.local/share/dolphin/view_properties/search/-GcD96GqLrtyEKc21tsud9GdNkQ=
8.0K    /tmp/sni-qt_python2.7_2798-v62G6z/icons/hicolor/32x32/apps
11G     /usr
12K     /tmp/sni-qt_python2.7_2798-v62G6z/icons/hicolor/32x32
16K     /tmp/sni-qt_python2.7_2798-v62G6z/icons/hicolor
20G     /
20K     /tmp/sni-qt_python2.7_2798-v62G6z/icons
24K     /tmp/sni-qt_python2.7_2798-v62G6z

Code:

linux-z76n:~ # find / -xdev -type f -size +1G -printf "%k\t%p\\n" | sort -g
2097156 /var/lib/systemd/coredump/.#core.kmail.1000.0626b2c04a6d4b8ca84ef03ee8b09bf9.8363.1491845311000000e1d41a4f34db545f
2097156 /var/lib/systemd/coredump/.#core.plasmashell.1000.0626b2c04a6d4b8ca84ef03ee8b09bf9.2085.1491845311000000e970ebe6a8e02d80
linux-z76n:~ #

Was sind die 5.1G in "/var/lib/systemd/coredump"?
Welche von allen o.g. Files kann ich sie sicher löschen?
und ... wie kann ich dieses Problem vermeiden?
Jetzt Bitte ich um Rat.... Danke

Folgende Kommandos sind von einer andere Maschine.... nur so als Info...

Code:

# du -xh / | grep [0-9][.,]*[0-9]G | sort -n
1,1G    /usr/share/icons
2,2G    /usr/lib64
3,0G    /usr/share
6,3G    /usr
7,3G    /
 # find / -xdev -type f -size +1G -printf "%k\t%p\\n" | sort -g
 #

gehrke · 19 Apr. 2017

Juan_Lutz schrieb:
Hallo Josef-Wien,

Gibt es einen besonderen Grund, warum Du den Rest der Community hier ausschließt?

Na egal - Coredumps werden bei Abstürzen geschrieben und sollen bei der Ursachenfindung helfen. Sie sind sehr groß und enthalten einen Haufen Debug-Informationen zum Zustand des Systems zum Zeitpunkt des Absturzes.
Falls Du diese nicht benötigst, solltest Du sie einfach löschen können. Eigentlich sollte so etwas nur in sehr seltenen Ausnahmefällen auftreten. Falls das häufiger vorkommt, solltest Du der Ursache auf den Grund gehen.

Juan_Lutz · 19 Apr. 2017

gehrke schrieb:
Juan_Lutz schrieb:

Hallo Josef-Wien,

Zum Vergrößern anklicken....

Gibt es einen besonderen Grund, warum Du den Rest der Community hier ausschließt?

Keiner soll sich Ausgeschlossen fühlen. War nur ein Tipp Fehler .... schon korrigiert !

gehrke schrieb:
Na egal - Coredumps werden bei Abstürzen geschrieben und sollen bei der Ursachenfindung helfen. Sie sind sehr groß und enthalten einen Haufen Debug-Informationen zum Zustand des Systems zum Zeitpunkt des Absturzes.
Falls Du diese nicht benötigst, solltest Du sie einfach löschen können. Eigentlich sollte so etwas nur in sehr seltenen Ausnahmefällen auftreten. Falls das häufiger vorkommt, solltest Du der Ursache auf den Grund gehen.

Danke für die Hinweise, ich werde sie löschen ... nur, kann ich auch andere Files löschen wie z. B.
/tmp/..?
/var/..?
Lg J.-L.

josef-wien · 19 Apr. 2017

/usr/src enthält vermutlich den Quellcode zweier Kernel, ansonsten deutet /usr darauf hin, daß mehr Programme installiert sind als beim Vergleichs-PC. /tmp dürfte kein Problem zu sein, aber die verbleibenden 1,5 G in /var könnten untersuchungswert sein:

Code:

du -xh /tmp /var | grep [0-9][0-9][0-9]M | sort -n

gehrke · 19 Apr. 2017

Also nach Löschen der Coredumps solltest Du ja erst mal wieder 5.1G Luft haben.

Lohnenswerte Kandidaten scheinen mir daneben zu sein:

Juan_Lutz schrieb:
Code:

6.6G /var 11G /usr

Bei /var tippe ich neben den Dumps auf ein überdimensioniertes journal bzw. die Logs und /usr scheint mir auch sehr groß.
Ein genaueres Bild solltest Du hiermit bekommen (entsprechend erweitern):

Code:

du -h --max-depth=1 /var

Juan_Lutz · 19 Apr. 2017

Hallo hier mein Bericht:

1. Coredumps Dateien wurden gelöscht. Das System läuft wieder

2. Jetzt Kommando "du -xh / | grep [0-9][.,]*[0-9]G | sort -n" sieht es so aus:

Code:

1,7G    /var
2,2G    /usr/src
3,2G    /usr/lib64
4,0G    /usr/share
8,0K    /root/.local/share/dolphin/view_properties/search/-GcD96GqLrtyEKc21tsud9GdNkQ=
8,0K    /tmp/sni-qt_python2.7_2798-v62G6z/icons/hicolor/32x32/apps
11G     /usr
12K     /tmp/sni-qt_python2.7_2798-v62G6z/icons/hicolor/32x32
14G     /
16K     /tmp/sni-qt_python2.7_2798-v62G6z/icons/hicolor
20K     /tmp/sni-qt_python2.7_2798-v62G6z/icons
24K     /tmp/sni-qt_python2.7_2798-v62G6z

3. Vorschlag (https://linux-club.de/wiki/opensuse/Tip ... d-tmpfiles) wurde gemacht.
4. Folgende Kommando "du -xh /tmp /var | grep [0-9][0-9][0-9]M | sort -n" sieht es so aus: Welche wäre ein Kandidat zu löschen?

Code:

142M    /var/spool
142M    /var/spool/cups
178M    /var/tmp/kdecache-juan-lutz-os422
180M    /var/lib/rpm
190M    /var/tmp
226M    /var/adm/backup
226M    /var/adm/backup/rpmdb
227M    /var/adm
236M    /var/cache
323M    /var/lib
457M    /var/log/journal
457M    /var/log/journal/85a689387aa60e504d971a6258b0c97b
527M    /var/log

hier noch das Kommando "du -h --max-depth=1 /var"

Code:

323M    /var/lib
12K     /var/games
227M    /var/adm
4,0K    /var/db
4,0K    /var/opt
190M    /var/tmp
236M    /var/cache
4,0K    /var/crash
142M    /var/spool
527M    /var/log
12K     /var/yp
1,7G    /var

Frage wie kann ich Coredumps vermeiden ( disable )?

Danke für die Unterstützung und weitere Hinweise.
Lg
Juan_Lutz

gehrke · 19 Apr. 2017

Noch einmal meine Bitte an Dich, zukünftig Code-Tags zu verwenden: https://linux-club.de/forum/viewtopic.php?f=92&t=105750
TNX

gehrke · 19 Apr. 2017

Juan_Lutz schrieb:
hier noch das Kommando "du -h --max-depth=1 /var"

Code:

527M /var/log

Code:

man journald.conf

Juan_Lutz schrieb:
Frage wie kann ich Coredumps vermeiden ( disable )?

Code:

man coredump.conf

gehrke · 19 Apr. 2017

gehrke schrieb:
Lohnenswerte Kandidaten scheinen mir daneben zu sein:

Juan_Lutz schrieb:

Code:

11G /usr

Zum Vergrößern anklicken....

Hier könnte es sich auch noch lohnen, genauer nachzuschauen. Zum Vergleich: unter CentOS ist es gerade mal die Hälfte:

Code:

[root@j2 ~]# du -h --max-depth=1 /usr
1,5G	/usr/lib
128M	/usr/libexec
136K	/usr/local
342M	/usr/src
1,8G	/usr/lib64
4,0K	/usr/games
2,2G	/usr/share
18M	/usr/include
305M	/usr/bin
4,0K	/usr/etc
60M	/usr/sbin
6,2G	/usr

[Gelöst] Root Partition voll... Meldung "Low Disk Space".

Juan_Lutz

josef-wien

Juan_Lutz

gehrke

Administrator

Juan_Lutz

gehrke

Administrator

Juan_Lutz

josef-wien

gehrke

Administrator

Juan_Lutz

gehrke

Administrator

gehrke

Administrator

gehrke

Administrator