Bullseye: journald erzeugt über 1 GB Daten pro Monat

[matman]

Hey Leute, mir ist gerade aufgefallen, das sich (in Bullseye) ein sehr problematischer Bug eingeschlichen hat. Der Ordner /var/log/journal/UUID hat sich seit Ende Juli, also bis jetzt binnen knapp 3 Monaten, um über 4 GB mit Daten angefüllt. Alle paar Tage werden da neue Dateien mit kryptischen Namen angelegt. Aber eben erst seit Ende Juli.

Das selbe habe ich seit Mitte September auf einem ähnlichen Bullseye System das ich soweit ich das richtig erinnere erst deutlich später mit Updates fütterte.

Hat jemand schon das selbe beobachtet und eine Idee wie man das beheben kann?

[mat6937]

... ein sehr problematischer Bug eingeschlichen hat.

Das ist kein Bug.

... eine Idee wie man das beheben kann?

Z. B. mit:

Code: Alles auswählen

Storage=volatile
RuntimeMaxUse=300M  # evtl. anpassen

oder beim default "Storage=auto" mit:

Code: Alles auswählen

SystemMaxUse=500M  # evtl. anpassen

Siehe auch die Konfigurationsmöglichkeiten der "/etc/systemd/journald.conf".

EDIT:

Siehe auch: https://www.freedesktop.org/software/sy ... temMaxUse=

[kalle123]

Oder

https://got-tty.org/journalctl-via-jour ... definieren

cu KH

[thunder11]

oder
in /etc/systemd/journald.conf

Code: Alles auswählen

MaxRetentionSec=1month

ergibt:

Code: Alles auswählen

journalctl --disk-usage
Archived and active journals take up 429.3M in the file system.

Siehe:
https://www.freedesktop.org/software/sy ... .conf.html

[JTH]

Code: Alles auswählen

MaxRetentionSec=1month

ergibt:

Code: Alles auswählen

journalctl --disk-usage
Archived and active journals take up 429.3M in the file system.

Das dürfte doch sehr vom einzelnen System abhängen

Auf meinem gerade letzte Woche neuen und frisch aufgesetzten Laptop hab ich hier schon:

Code: Alles auswählen

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

(Gab anfangs noch ein paar Baustellen mit viel Loggerei.)

[thunder11]

Das dürfte doch sehr vom einzelnen System abhängen

vielleicht deshalb ?

Code: Alles auswählen

Collecting audit messages is disabled.

Code: Alles auswählen

systemctl status systemd-journald-audit.socket
○ systemd-journald-audit.socket - Journal Audit Socket
     Loaded: loaded (/lib/systemd/system/systemd-journald-audit.socket; disabled; preset: enabled)
     Active: inactive (dead)
   Triggers: ● systemd-journald.service
       Docs: man:systemd-journald.service(8)
             man:journald.conf(5)
     Listen: audit 1 (Netlink)

Und:
Ich bin ja ehrlich: hatte neulich das Journal geputzt (wg diesen gnome-logs) und jetzt fängt es erst am 05.10.23 an

Code: Alles auswählen

systemctl status systemd-journald 
● systemd-journald.service - Journal Service
     Loaded: loaded (/lib/systemd/system/systemd-journald.service; static)
     Active: active (running) since Mon 2023-10-16 07:40:08 CEST; 6h ago
TriggeredBy: ● systemd-journald-dev-log.socket
             ● systemd-journald.socket
             ○ systemd-journald-audit.socket
       Docs: man:systemd-journald.service(8)
             man:journald.conf(5)
   Main PID: 407 (systemd-journal)
     Status: "Processing requests..."
      Tasks: 1 (limit: 38076)
   FD Store: 44 (limit: 4224)
     Memory: 29.6M
        CPU: 696ms
     CGroup: /system.slice/systemd-journald.service
             └─407 /lib/systemd/systemd-journald

Okt 16 07:40:08 XFCE systemd-journald[407]: Collecting audit messages is disabled.
Okt 16 07:40:08 XFCE systemd-journald[407]: Journal started
Okt 16 07:40:08 XFCE systemd-journald[407]: Runtime Journal (/run/log/journal/d3183aefaece487590ec39f41cee5f47) is 8.0M, max 317.5M, 309.5M fre>
Okt 16 07:40:08 XFCE systemd-journald[407]: Time spent on flushing to /var/log/journal/d3183aefaece487590ec39f41cee5f47 is 49.995ms for 915 ent>
Okt 16 07:40:08 XFCE systemd-journald[407]: System Journal (/var/log/journal/d3183aefaece487590ec39f41cee5f47) is 429.2M, max 4.0G, 3.5G free.
Okt 16 07:40:08 XFCE systemd-journald[407]: Received client request to flush runtime journal.
Okt 16 07:40:08 XFCE systemd-journald[407]: /var/log/journal/d3183aefaece487590ec39f41cee5f47/system.journal: Journal file uses a different seq>
Okt 16 07:40:08 XFCE systemd-journald[407]: Rotating system journal.
Okt 16 07:40:11 XFCE systemd-journald[407]: /var/log/journal/d3183aefaece487590ec39f41cee5f47/user-1000.journal: Journal file uses a different >
Notice: journal has been rotated since unit was started, output may be incomplete.
lines 1-27/27 (END)

[mat6937]

Code: Alles auswählen

Collecting audit messages is disabled.

Code: Alles auswählen

systemctl status systemd-journald-audit.socket
○ systemd-journald-audit.socket - Journal Audit Socket
     Loaded: loaded (/lib/systemd/system/systemd-journald-audit.socket; disabled; preset: enabled)
     Active: inactive (dead)

BTW: Wenn es nur deaktiviert ist, könnte es aber von anderen Diensten evtl. doch noch gestartet werden. Verhindern kann man das Starten, mit "mask":

Code: Alles auswählen

systemctl status systemd-journald-audit.socket
● systemd-journald-audit.socket
     Loaded: masked (Reason: Unit systemd-journald-audit.socket is masked.)
     Active: inactive (dead)
   Triggers: ● systemd-journald.service

[matman]

Das ist kein Bug.

Naja... wenn wegen einem routinemäßigen Update die Festplatte überquillt, dann ist das für mich ein sehr schlimmer Bug. Glücklicherweise waren noch einige MB frei nach den Download der deb Pakete und deren vollständiger Installation. Aber ich will nicht wirklich wissen was passiert wäre, wenn der Download für das Update 100 MB größer gewesen wäre, was ja durchaus sein kann. Ist halt eine kleine Platte und kleines Sys, also kaum mehr als 500 MB Downloads für Updates und bisher immer gute 3 bis 4 GB Reserve.

Aber wie mir scheint wurde in Bullseye plötzlich das Log-System geändert. Habe da jedenfalls sowas beim googeln gesehen. Da gab es irgendwo einen Artikel das dieses journald neu ist in Bookworm. Dachte daher erst das es dann ja nichts zu tun hat mit Bullseye, aber da habe ich mich wohl geirrt.

Bisher hatte ich selten deutlich mehr als 1 GB im Log-Verzeichnis. Nur wenn mal wegen einem Bug ein Tool extrem viele Logeinträge verursachte.

Was ist denn so toll daran, das man jetzt plötzlich in so kurzer Zeit so wahnsinnig viele Daten sammelt? Wo sind da die Vorteile? Scheint ja gigantisch toll zu sein.

[GregorS]

Das ist kein Bug.

Naja... wenn wegen einem routinemäßigen Update die Festplatte überquillt, dann ist das für mich ein sehr schlimmer Bug.

Ein Update sollte halt nie so routinemäßig sein, dass man hinterher nicht auch mal prüft (zwei-/dreimal im Abstand von ein paar Tagen oder so), ob etwas aus dem Ruder läuft. Der „Bug“ ist IMO ziemlich hausgemacht.

Gruß

Gregor