Journalctl Flooding

[Harakiri]

Hallo,

ich habe einen Netzwerkkartentreiber der mehrfach pro Sekunde unentwegt Warnmeldungen an Journalctl raushaut:

Code: Alles auswählen

Sep 22 11:17:12 creeper kernel: RTW: [HALMAC][TRACE]get_hw_value_8821c ===>
Sep 22 11:17:12 creeper kernel: RTW: [HALMAC][TRACE]get_hw_value_88xx ===>
Sep 22 11:17:12 creeper kernel: RTW: [HALMAC][TRACE]get_hw_value_88xx <===
Sep 22 11:17:12 creeper kernel: RTW: IEEE 802.11 element parse ignored unknown element (id=7 elen=6)
Sep 22 11:17:12 creeper kernel: RTW: IEEE 802.11 element parse ignored unknown element (id=74 elen=14)
Sep 22 11:17:12 creeper kernel: RTW: IEEE 802.11 element parse ignored unknown element (id=127 elen=8)
Sep 22 11:17:12 creeper kernel: RTW: unknown vendor specific information element ignored (vendor OUI 00:03:7f len=9)

Ich habe bislang keine Möglichkeit gefunden das Ganze zu filtern bevor es mein Journalctl zumüllt. Mein bester Versuch war bisher in Journald.conf die Priorität der Einträge auf

Code: Alles auswählen

MaxLevelSyslog=err

zu setzen. Default wäre sonst

Code: Alles auswählen

MaxLevelSyslog=debug

Leider wird somit aber etwas zuviel weggelassen.

Ich befürchte, dass eine Filterfunktion bereits in der Entstehung im Journalctl nicht vorgesehen ist, wie die Äußerungen von Poettring hier vermuten lassen. https://github.com/systemd/systemd/issues/6432

Mit Rsyslog geht das wohl, was mir bei Journalctl leider nicht weiter hilft: https://www.rsyslog.com/discarding-unwanted-messages/

Weiß vielleicht jemand irgendwie Rat hierzu?

[kalle123]

Vielleicht ...

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

Gruß KH

[smutbert]

Wenn MaxLevelSyslog prinzipiell den erwünschten Erfolg zeigt, gäbe es zwischen debug und err ja noch info, notice und warning.

[Harakiri]

@kalle123
Naja, die Loggröße habe ich bereits eingestell. Leider hilft es nicht dagegen, dass die Meldungen vor der Aufnahme in Journalctl aufgenommen werden. Gefühlte 99% der Einträge sind dann immer noch Müll.
Überhaupt kalle123, wie hast du es hingekriegt deinen Ryzen stabil unter Linux laufen zu lassen? Das Internet ist voll mit Beiträgen in denen die Betroffenen erhebliche Probleme haben.
Seit kurzem habe ich ein Lenovo Laptop mit Ryzen 5 2500 und Vega-Gpu und kämpfe seitdem verzweifelt darum die regelmäßigen Freezes zu beseitigen.
Das bisher Erfolgreichste war das Deaktivieren des C6-States der cpu. Unter verschiedenen Kerneln (4.19, 5.2, 5.3) schmiert mir das Ganze leider immer wieder im Leerlauf ab. Ganz zu schweigen davon, dass bislang keine amdgpu-Firmware für Raven Ridge richtig funktioniert. Es ist zum Heulen.


@smutbert
Die unterschiedlichen Level im Journald.conf hab ich schon durch. Erst bei err wird das Unerwünschte gefiltert. Ich lasse das erst mal so eingestellt, aber es wird dann zu viel gefiltert, was ein schlechter Kompromiss für mich ist.

[kalle123]

@ Harakiri.

Zumindest läuft dir /var/log/journal/ danach nicht mehr über.

Zum AMD Ryzen. Mir sind wohl die Probleme mit den 'G' Versionen bekannt, aber der 'normale'?

Ich hab Ende letzten Jahres das System neu aufgebaut und muss sagen, super stabil. Einziger Ausreisser war die passive Gigabyte Nvidia GT1030.
Musste die nach 5 Monaten reklamieren. Ersatz ist drin und wie schon gesagt, läuft wie ein Schweizer Uhrwerk. https://debianforum.de/forum/v ... 3&t=174013

Grüße KH

[Harakiri]

So, nach tagelangem Grübeln konnte ich konnte ich doch noch eine individuelle Lösung finden.
Die Einstellungsmöglichkeiten in journald.conf noch /dev/kmsg waren für mich zu grob.

Da meine Realtekkarte rtl8821ce (https://github.com/endlessm/linux/tree/ ... /rtl8821ce) ein nichtoffizielles Kernelmodul benötigt, habe ich mit meinen minimalen Programmierkenntnissen im Sourcecode des Moduls die Stelle gefunden, die für den Debuglevel verantworlich ist. Nachdem ich dieses Level runter gesetzt hatte, habe ich dieses Modul noch mal erstellt und bekomme bis jetzt nicht mehr gigabyteweise nutzlose Debugmeldungen.

Leider war das Ganze allerdings etwas vom Glück abhängig, den einen effektiven Journalfilter der bereits in der Entstehung den Müll filtern kann, habe ich weder bei journald.conf noch bei dmesg gefunden.

[KP97]

In der Kernelzeile des Grub könnte dieser Eintrag helfen:
loglevel=2

[kalle123]

Glaube, hatten wir hier schon mal
https://debianforum.de/forum/viewtopic ... 6#p1212685

cu KH

[smutbert]

loglevel wirkt sich darauf aus, was auf die Konsole geschrieben wird und ist damit nur ein Zusatz zur Option quiet.

Harakiri geht es aber um das Log und dass sich die Meldungen dieses Treibers anhand der Priorität nicht sinnvoll filtern lassen, weswegen loglevel=x sowieso nicht helfen kann.

[KP97]

...stimmt auch wieder...

[Harakiri]

Also wen es interessiert, /dev/kmsg und damit auch dmesg lassen sich in der sysctl.conf mit printk einstellen.

Hier ein englischsprachiger Link dazu, der hat mir gut geholfen:
https://superuser.com/a/793692

Leider ist es manchmal nahezu unmöglich die Quelle von Debugmeldungen zu blockieren. Das finde ich nicht gut.