Wie deaktiviere ich die Kernel-Protokollierung im systemd-Journal?

1285
Luke F

Ich verwende ein Gerät, das übermäßig viele Kernel-Nachrichten spammt (10-100 Nachrichten pro Sekunde, Mediatek-Treiber ...), wobei es unmöglich ist, die Protokollierung aus dem Kernel selbst zu entfernen (über Hunderte von Dateien verteilt).

Ich habe akzeptiert, dass dmesg auf diesem Gerät so gut wie unbrauchbar ist, aber leider ist auch das systemd-Journal betroffen.

Ist es möglich, Kernel-Meldungen im systemd-Journal zu filtern oder zu deaktivieren?

3
Anstatt die Protokollierung von Kernel-Nachrichten zu deaktivieren, würde ich untersuchen, warum Mediatek-Treiber eine so hohe Ausgabe erzeugen und was dagegen getan werden kann. Kernel-Nachrichten sind sehr nützlich. MariusMatutiae vor 5 Jahren 0
Ich stimme völlig zu, aber die Ausgabe dieser Mediatek-Treiber ist einfach lächerlich. Es spendet mehrere Zeilen (aller verfügbaren Prioritäten) für Dinge wie das Ein- und Ausschalten eines CPU-Kerns oder die Änderung der Batteriespannung um einen winzigen Betrag. Es gibt keine Möglichkeit, den Spam zu stoppen, den ich sehen kann. Jeder Treiber verwendet eine eigene, hartcodierte Protokollierungskonfiguration. Am besten kann ich die schlechtesten Täter auskommentieren Luke F vor 5 Jahren 0

2 Antworten auf die Frage

4
baelx

Eine gute Linux / Sysadmin-Praxis würde Ihnen empfehlen, sich für eine Lösung wie die von fzbd zu entscheiden, in der Sie das spezifische Protokoll stummschalten, das Sie nicht sehen müssen, statt die Kernel-Nachrichten vollständig zu deaktivieren.

Dennoch ist es noch erwähnenswert, dass es ab systemd 235 eine Option gibt, um Kernel-Messeges in einer journald.confDatei zu deaktivieren . Die wichtigsten journal.conf-Dokumente erwähnen diese Option, mit der Sie das Lesen von Journald deaktivieren können /dev/kmsg.

Die Version 235 ist möglicherweise in vielen Distributionen noch nicht vorhanden. Sie können Ihre systemd-Version also mit folgendem Befehl prüfen:

systemctl --version

Wenn Sie Version 235 oder höher Sie zuerst eine Sicherungskopie der ursprünglichen Datei /etc/systemd/journald.conf gehen und dann uncommenting die entsprechende Zeile und ändert es von yeszu no:

ReadKMsg=no

Speichern, beenden Sie Ihren Journaldienst und starten Sie ihn erneut:

sudo systemctl restart systemd-journald.service
Vielen Dank, installiertes systemd von stretch-backports und ReadKMsg = no hat den Trick! Luke F vor 5 Jahren 1
Anstelle von edit /etc/systemd/journald.conf ist es besser, sie zum Beispiel mit /etc/systemd/journald.conf.d/kfilter.conf zu überschreiben. Oleg Kr vor 5 Jahren 0
@ Oleg Ja, Modularisierung der Dinge ist in der Regel eine gute Praxis, wenn ja, also ja, das wäre auch eine gute Option. baelx vor 5 Jahren 0
3
fzbd

Prüfen Sie, ob das Kernel-Modul Ihres Geräts über einige Protokollierungs- / Debug-Parameter verfügt, die Sie deaktivieren können:

modprobe $module_name ls /sys/module/$module_name/parameters

Ist dies nicht der Fall, können Sie bei systemd mit der Version <235 die Nachrichten am besten nach Protokollierebene filtern. Beispiel:

journalctl --priority=3

Sie können die Protokollwerte mit überprüfen man syslog.

Beachten Sie, dass das Herabsetzen der Kernel-Protokollierungsstufen kernel.printknur die Konsolenprotokollierung beeinflusst, so dass Benutzerlandanwendungen unabhängig von den Werten in diesem Parameter immer noch dieselben Meldungen anzeigen.

Soweit ich weiß, betrifft kernel.printk nur die Kernel-Protokollierung in TTYs? Leider gibt es keine exponierten Parameter für die für den Spam verantwortlichen Treiber Luke F vor 5 Jahren 0
Sie haben recht, Aufrufe von printk () werden auf journalctl angezeigt. Ich habe meine Antwort überarbeitet. fzbd vor 5 Jahren 0

Verwandte Probleme