Speicherplatz im Basisordner knapp

Hallo werte OpenSuse Benutzer,

mir wird seit einigen Tagen nach dem booten eine Meldung angezeigt:

“Der Speicherplatz im Basisordner wird knapp.
Es verbleiben noch 0 MiB (0%).”

suse_user2@Tuxedo2020:~> df -l
Dateisystem     1K-Blöcke   Benutzt  Verfügbar Verw% Eingehängt auf
devtmpfs             4096         8       4088    1% /dev
tmpfs             8153044         4    8153040    1% /dev/shm
tmpfs             3261220    157108    3104112    5% /run
tmpfs                4096         0       4096    0% /sys/fs/cgroup
/dev/sda9        51290592  45155596    3497172   93% /
/dev/sda5          572304     12616     559688    3% /boot/efi
/dev/sdb2      5652528112 779013916 4586309028   15% /home
tmpfs             1630608        60    1630548    1% /run/user/1000

Ich kann nichts auffälliges feststellen.
Wie kann ich das Problem lösen? Danke für eure Hilfe.

filelight zeigt das an:
https://paste.opensuse.org/pastes/7e07a8ec1873

Gruß, su_lin_user1

3,5 GB noch verfügbar…

Läuft da btrfs, sind dort Schnappschüsse eingestellt?

Hallo Sauerland,

nein, das filesystem ist ext4. Ich habe vorhin gerade mal den Papierkorb geleert; da ist auch wieder was frei geworden.
Sollte man die root-Partition von 50GB auf … vergrößern? Bisher waren 50 GB immer ausreichend, egal wie voll der Papierkorb war.

Hallo,

also ich habe inzwischen den noch freien Speicherplatz von 20 GB der sda9 zugewiesen. Mal sehen, ob das schon was nützt.
Die 93% Speicherplatzbelegung von sda9 waren jedoch auch schon vor dem ich den Papierkorb geleert habe vorhanden. Deshalb bin ich mir nicht ganz sicher, ob die zusätzlichen 20GB global einen Nutzen haben. Vielleicht fehlt es an einer bestimmten Stelle? Mal abwarten. Bis jetzt ist die Meldung nicht wieder gekommen.

Gruß, su_lin_user1

Schau mal unter /var/log und /var/log journal. Die laufen gern voll wenn man ungünstige oder gar keine individuellen Einstellungen der journald.conf vorgenommen hat.

Siehe auch “man journald.conf”

Wo glaubst du das das sich befindet wenn man ein separates Dateisystem fur /home hat?

1 Like

Also, wenn ich die Grafik von filelight richtig deute, sind mehr als drei Viertel der 46,5 GiB durch /var/ belegt. Es ist wohl sehr wahrscheinlich, dass hui mit der /var/log - Vermutung Recht hat.
@su_lin_user1, ich finde in solchen Fällen übrigens k4dirstat (als root) sehr hilfreich. Bei den vielen Subvolumes von BTRFS ist es etwas mühselig, immer wieder von den Moutpoint neu zu starten, aber man kommt recht bald auf die richtige Spur. Mit ext4 sollte es gut funktionieren.

Edit: Sorry, habe vergessen zu erwähnen, dass ich KDE benutze. Ich weiß nicht, ob / wie es auch in anderen Umgebungen läuft.
“Als root”: am besten mit Alt+F2 - dann kdesu k4dirstat.

Hallo werte Pinguine,

@hui

suse_user1@Tuxedo2020:/var/log> sudo du -sh ./
[sudo] Passwort für root: 
33G     ./

Das Verzeichnis /var/logjournal existiert nicht.

suse_user1@Tuxedo2020:/var> ls -la
insgesamt 52
drwxr-xr-x 10 root root  4096  9. Jun 05:38 .
drwxr-xr-x 23 root root  4096 24. Jun 08:36 ..
drwxr-xr-x  6 root root  4096  9. Jun 05:38 adm
lrwxrwxrwx  1 root root    11  9. Jan 2023  agentx -> /run/agentx
drwxr-xr-x 15 root root  4096 10. Jun 14:33 cache
drwxr-xr-x  2 root root  4096 15. Mär 2022  crash
drwxr-xr-x 51 root root  4096 10. Jun 14:33 lib
lrwxrwxrwx  1 root root     9  9. Jun 05:29 lock -> /run/lock
drwxr-xr-x 15 root root 12288 15. Aug 10:56 log
lrwxrwxrwx  1 root root    10 15. Mär 2022  mail -> spool/mail
drwxr-xr-x  2 root root  4096 15. Mär 2022  opt
lrwxrwxrwx  1 root root     4  9. Jun 05:29 run -> /run
drwxr-xr-x 11 root root  4096  9. Jun 05:34 spool
drwxrwxrwt 13 root root  4096 15. Aug 10:59 tmp
-rw-r--r--  1 root root   208  9. Jun 05:32 .updated

Sind 33GB Belegung für das /var/log viel ? von 50 GB Gesamtspeicherplatz vielleicht schon ! Wie groß sollte eine gesunde Belegung in etwa sein ?
Aber was jetzt machen ? Wenn löschen, was löschen ? Kannst Du dazu einen Tipp geben ?

@hcvv
Ja, der Papierkorb ist natürlich im /home, das hab ich gerade nicht mehr vor Augen gehabt.

@kasi042
Ich habe k4dirstat noch nie benutzt, obwohl ich auch KDE verwende. Wenn es um Partitionen und Speicher geht nehme ich GParted, wie wahrscheinlich die meisten.

Gruß, su_lin_user1

k4dirstat zeigt an, wieviel Speicher in den jeweiligen Verzeichnissen belegt ist. Und ja, 33G Log-Dateien ist sehr viel. :wink:

Bei mir (LEAP 15.4):

boven:/var # du -sh log
964M    log
boven:/var #

Und ich tue eigentlich nichts daran um das zu verwalten.

Tut das eine Aussage darüber wieviel innerhalb ein Dateisystem unbenutz ist?

Ich benutze nie Gparted Und gehöre also nicht zu “die Meisten”), also kann ich darüber nicht viel sagen, aber ich bezweifle.

Hallo,

ja, das ist viel. Wie von anderen bereits suggeriert handelt es sich meist um ein fehlkonfiguriertes Programm welches Unmengen an Logausgaben schreibt ohne diese aufzuräumen. Es kann aber auch ein Programm sein welches ein erhöhtes Fehleraufkommen hat und versucht auf sich aufmerksam zu machen, in welchem Fall hier die Ursache zu suchen wäre.

Am besten gehst du mit deiner du Recherche noch eine Ebene weiter und schaust, welche Dateien bzw. Verzeichnisse in /var/log/ den meisten Platz verbrauchen. Beispiel:

sudo du -h -d 1 /var/log | sort -h

Alternativ kannst du natürlich auch eines der empfohlenen grafischen Werkzeuge hierfür nutzen.

Wenn du mit den Inhalten selbst nicht weiter weißt, kannst du die Ausgabe gerne wieder posten und wir können das problematische Programm ausfindig machen.

Hallo,

Ja, man kann es grafisch als GParted benutzen, oder vom Terminal im Befehlszeilenmodus als Parted. Parted ist ähnlich wie fdisk.

@crameleon
Der PC booted jetzt gar nicht mehr. Der Bootvorgang ist extrem langsam bis zur Bootauswahl, obwohl von SSD, und endet im Zeitlupentempo im emergency mode für Wartungszwecke. Und das nicht nur mit Leap 15.5, auch mit Tumbleweed.
Windows lässt sich noch booten.
Ich poste von einem anderen PC aus.

Gruß, su_lin_user1

Hallo,
@crameleon

vom emergency mode aus:

“Zugriff auf ‘1’ nicht möglich: Datei oder Verzeichnis nicht gefunden”
/var/log hat 35GB.

fdisk hat keine Ahnung von Dateisystemen. Und erst recht nicht wie voll es ist.

Wenn dein System nicht mehr startet und dein /var/log nun 35 von 50GB hat, dann ist deine root Partition endgültig vollgelaufen und jetzt muss man zu harten Schritten greifen.

Wenn du auf ein Terminal zugreifen kannst, musst die Inhalte von /var/log/journal/ löschen (ich hatte oben in meinem Post einen Schreibfehler und den Slash vergessen, deswegen hast du den Ordner nicht gefunden…).

sudo rm -rf /var/log/journal/*

Danach neustarten und die Größe von /var/log/ überprüfen. Wie crameleon bereits angedeutet hat, muss es nicht zwingend das journal gewesen sein, was dir /var/log/ vollschreibt.

Deshalb: journal löschen, Größen checken. Wenn nur ein geringer Speicherplatz freigeworden ist, war es nicht das journal und du musst sofort mit der Suche in den Unterordnern von /var/log anfangen.

Wenn ein großer Speicherbereich frei wird, war es das journal und du solltest dann die /etc/systemd/journald.conf konfigurieren.
Folgende Einstellungen habe ich zum Beispiel in meiner config drin:

[Journal]
#Storage=auto
Compress=yes
#Seal=yes
#SplitMode=uid
#SyncIntervalSec=5m
#RateLimitIntervalSec=30s
#RateLimitBurst=10000
SystemMaxUse=300M
#SystemKeepFree=
#SystemMaxFileSize=
#SystemMaxFiles=100
#RuntimeMaxUse=
#RuntimeKeepFree=
#RuntimeMaxFileSize=
#RuntimeMaxFiles=100
#MaxRetentionSec=
#MaxFileSec=1month
#ForwardToSyslog=no
#ForwardToKMsg=no
#ForwardToConsole=no
#ForwardToWall=yes
#TTYPath=/dev/console
#MaxLevelStore=debug
#MaxLevelSyslog=debug
#MaxLevelKMsg=notice

Das heißt, compress und SystemMaxUse=300M

Dann kann dein Journal nur noch 300MB groß werden.
Trotzdem solltest du dann dein journal inspizieren warum es so massiv anwächst…

Du solltest aber auch hier noch ein paar Aussagen dazu treffen:

Befinden sich Leap und TW auf der gleichen SSD aber unterschiedlichen Partitionen oder zwei getrennte SSDs?? Ist Windows eine eigene SSD oder auch auf einer der ersteren?

Das riecht so, als ob eine deiner SSDs Hilfesignale (ich sterbe) ins journal gespammt hat und nun die SSD endgültig am sterben ist. Aber das ist nur eine Vermutung auf Grund unzureichender Faktenlage…

Und noch eine Empfehlung: trete solchen graphischen Tools wie filelight gparted und wie der “Schrott” sonst noch so heißt alle in die Tonne. Ich musste mal für eine andere Distrie für die Bugsuche auf einem Rechner alle möglichen graphischen Tools nutzen. Jedes graphische Tool hat was anderes angezeigt…und alle falsch. Terminalwerkzeuge oder der klassische Dateimanager in der Detailansicht gibt dir korrekte Größen aus! Immer!

Hallo,
@hui

Das Verzeichnis …/journal/ existiert wirklich nicht. Den meisten Speicherplatz in /var/log/ von 35GB füllen warn-Meldungen und message-Meldungen.

Leap und TW befinden sich auf getrennten Partitionen. Das /var/log/ von TW ist fast leer. Windows ist auf der gleichen SSD, aber natürlich anderen Partition installiert.

die journald.conf bei mir hat exakt die gleichen Einstellungen, außer der Eintrag SystemMaxUse= ist noch ohne Angabe.

Tue doch erst einmahl alles in /var/log/ was auf .xz endet weg, das du etwas Luft kriegst.

Sowas sagt man nicht. Man zeigt mit z.B.

ls -l ...

oder auch einanderes Kommando womit du das gefunden hast. Wit glauben dich wirklich nicht. Wit glauben nur das was du per Copy/Paste hier zeigst.