[behoben] Knapp 12 GB /var/log/journal

Server v7
1

Hallo,

folgende Info nur zur Kenntnis, das Problem (Bug?) scheint mit „meiner Methode“ behoben.
EDIT, Lese-Tipp:
alle, bei denen unter „/var/log/journal“ nicht mehrere GB belegt sind, brauchen eigentlich nicht weiter lesen :wink:

LMLv7 Server,

root@server:~# dpkg -l | grep linuxm
ii  linuxmuster-base7                  7.0.81-0ubuntu0  
ii  linuxmuster-client-servertools     0.9d     
ii  linuxmuster-linbo-common7          2.4.3-2
ii  linuxmuster-linbo7                 2.4.3-2

wir sind gerade dabei auf neue Hardware zu migrieren. Dabei habe ich mir noch mal die Partitionsbelegung betrachtet und bin auf das Verzeichnis:

/var/log/journal

gestoßen, das knapp 12 GB groß war.

root@server:~# journalctl --disk-usage
Archived and active journals take up 11,7G in the file system.

Nach etwas Recherche bin ich auf die Bereinigungsbefehle:

journalctl --vacuum-time=2d
journalctl --vacuum-size=500M

Und Einstellungsparameter in der

/etc/systemd/journald.conf gestoßen.
Doch egal was ich gemacht habe, inkl. Reboot, das blieb alles wie in unzähligen Threads nachzulesen unwirksam, siehe zB:
Systemd logs (journalctl) are too large and slow
journalctl --vacuum-* --directory… does not remove anything in remote journal storage
Entgegen dem letzten Post ist das Problem in diesem Thread bis zum Schluss nicht gelöst.
Bei all meinen Versuchen blieben die 11,7GB völlig unverändert, mit Dateien weit über ein Jahr alt.

Also habe ich mich entschlossen, die harte Tour anzuwenden:
Ich habe ein „find“ und „rm“ Befehl abgesetzt, der sicher nicht allgemeingültig ist :wink:
Habe damit das UnterVerzeichnis (/var/log/journal/5cf30ec0a7d84f20843ac8c0c986262d/) geleert.
Dann habe ich die im Internet zu findenden Parameter für die Begrenzung der Größe in die Datei : „/etc/systemd/journald.conf“ geschrieben (ein paar Hundert MB.
Reboot - und siehe da…
Nach ein paar Stunden waren wieder ein Paar MB angewachsen, ABER:
Bereits jetzt konnte ich obige Befehle zur Bereinigung absetzten und anstatt wie zuvor, mit immer dem selben „0B“ Ergebis, funktionieren die Befehle plötzlich wieder:

root@server:~# journalctl --disk-usage
Archived and active journals take up 408.0M in the file system.

und

root@server:~# journalctl --vacuum-size=300M
Deleted archived journal /var/log/journal/5cf30ec0a7d84f20843ac8c0c986262d/system@122e58391c3d44fc94a6caf78208fb22-000000000000077a-0005c3647e5be709.journal (56.0M).
Deleted archived journal /var/log/journal/5cf30ec0a7d84f20843ac8c0c986262d/system@122e58391c3d44fc94a6caf78208fb22-000000000000e02b-0005c36b4d226f02.journal (48.0M).
Vacuuming done, freed 104.0M of archived journals from /var/log/journal/5cf30ec0a7d84f20843ac8c0c986262d.
Vacuuming done, freed 0B of archived journals from /var/log/journal.

Grüße,
gerd

1 „Gefällt mir“
2

Hallo Gerd.
Hm – kann ich nicht bestätigen. Zum einen habe ich das Verzeichnis hier gar nicht und zum anderen meldet journalctl --disk-usage lediglich:
Archived and active journals take up 104.0M in the file system.

Seltsam…
Viele Grüße,
Michael

3

Hallo Michael,
gut zu wissen.
Eine erste Erklärung wäre, das sehr frühe Stadium, zu dem wir die LMLv7 aufgesetzt hatten.
Für mich stellt sich das so dar, dass das automatische Bereinigen bei uns noch nie funktioniert hat.
Bei dir schon ;-))
Aber gerda weil ich im Internet auf haufenweise Posts gestoßen bin, mit dem selben Problem, habe ich mich entschlossen das auch hier zu posten…
Deswegen ist dein Vergleich auch gut.
Ich gehe auch davon aus, dass das Problem bei uns nicht mehr auftreten wird und ab jetzt auch wieder die automatisch Bereinigung greift. Scheint also ein Versionsabhängiges Problem zu sein.

Grüße in den Norden,
gerd

4

Hallo Gerd,

meine lmn7 wurde in den Sommerferien 2019 aufgesetzt.

Ich habe:

journalctl --disk-usage
Archived and active journals take up 1.4G in the file system.

Ist das viel?

Meine /etc/systemd/journald.conf:

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

Da ist also gar nichts konfiguriert…

LG

Holger

5

Hallo Holger,

nein, ich denke nicht.
Nachdem ich bei uns geleert hatte, waren bereits nach wenigen Stunden schon wieder ein paar Hundert MB voll. Aber das eigentliche Problem war bei uns, dass überhaupt keine automatische Bereinigung feststellbar war und auf jeden fall sämtlich oben gezeigten manuellen Befehle zum Aufräumen und Löschen absolut ins leere liefen, immer mit der gleichen Ausgabe „freed 0B“ .
Erst seit dem manuellen Leeren funktionierten bei uns überhaupt die Befehle wieder.
In der „/etc/systemd/journald.conf’“ ist standardmäßig alles auskommentiert, nichts aktiv.
Ich habe auch aus Testgründen, folgende Optionen gesetzt:

root@server:~# cat /etc/systemd/journald.conf  |  grep "^[^#]" 
[Journal]
Storage=auto
SystemMaxUse=500M
SystemMaxFiles=100

Die werden bei uns nun auch berücksichtigt, indem die Speicherbelegung grob bei 500 MB gehalten wird.
Was hier „best pactice“ ist weiss ich nicht.
Ich gehe sehr stark davon aus, dass das ein längst behobener Bug war.
Denn ich habe zwar zahlreiche Post mit exakt unserem Fehlverhalten gefunden, dieser Fehler sollte aber in aktuellen Versionen, auch der gegenwärtigen in 18.04, längst behoben sein.
Anscheint hat’s bei unserem Ubuntu noch einen Tritt in den Hintern gebraucht, damit das System wieder richtig arbeitet

Grüße,
gerd

6

Die Lösung hatte Gerd ja schon selber geliefert, daher dieser Beitrag um den Thread als gelöst zu markieren: siehe [behoben] Knapp 12 GB /var/log/journal