Verringern Sie die Ausführlichkeitsstufe des Kernel-Boot-Protokolls

Wenn mein Kernel startet, werden neben den nützlichen wichtigen Informationen viele Debugging-Informationen gedruckt, z

....
kernel: [0.00000] BIOS-e820: [mem 0x0000000000000000-0x000000000009d3ff] usable
kernel: [0.00000] BIOS-e820: [mem 0x000000000009d400-0x000000000009ffff] reserved
kernel: [0.00000] BIOS-e820: [mem 0x00000000000e0000-0x00000000000fffff] reserved
...
kernel: [0.00000] MTRR variable ranges enabled:
kernel: [0.00000]   0 base 0000000000 mask 7E00000000 write-back
...
kernel: [0.00000] init_memory_mapping: [mem 0x00100000-0xcf414fff]
kernel: [0.00000]  [mem 0x00100000-0x001fffff] page 4k
kernel: [0.00000]  [mem 0x00200000-0xcf3fffff] page 2M
kernel: [0.00000]  [mem 0xcf400000-0xcf414fff] page 4k
....
kernel: [0.00000] ACPI: XSDT 0xD8FEB088 0008C (v01 DELL CBX3 01072009 AMI 10013)
kernel: [0.00000] ACPI: FACP 0xD8FFC9F8 0010C (v05 DELL CBX3 01072009 AMI 10013)
....
kernel: [0.00000] Early memory node ranges
kernel: [0.00000]   node   0: [mem 0x00001000-0x0009cfff]
kernel: [0.00000]   node   0: [mem 0x00100000-0xcf414fff]
kernel: [0.00000]   node   0: [mem 0xcf41c000-0xcfdfcfff]
....
kernel: [0.00000] ACPI: Local APIC address 0xfee00000
kernel: [0.00000] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
kernel: [0.00000] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x02] enabled)

und sehr viel mehr.

Ich sehe nicht ein, wie dies für andere als einen Kernel-Entwickler / Debugger nützlich sein kann.

Ich habe festgestellt, dass ich diese durch Verwendung loglevel=5als Boot-Parameter entfernen kann. Die Debugging-Protokolle werden nicht mehr auf dem Terminal gedruckt, befinden sich jedoch weiterhin in dmesgund in syslog.

Ist es möglich , die Boot - Protokoll Ausführlichkeit global zu verringern, so dass dmesgund syslognicht von diesen nutzlosen Informationen überflutet werden?

Ich benutze einen selbst kompilierten Kernel 3.18

AKEPTIERTE LÖSUNG

Es stellt sich heraus, dass ich folgende Zeilen /etc/rsyslog.confeingefügt habe, um das Problem für mich zu lösen:

kern.debug   /dev/null
& ~

Für Syslog Sie können folgende Zeile hinzufügen /etc/syslog.conf:

kern.info; kern.debug   /dev/null

Kernel-Info- und .debug-Nachrichten werden verworfen (die mit loglevel = 5 verworfen werden).

Auch dmesgkann mit Option -nNachrichten mit bestimmten loglevel zu zeigen.

Einige der Protokolle werden von printk () gedruckt, das Sie nicht deaktivieren konnten. Und einige werden von pr_debug () gedruckt, was abhängig von der Konfiguration des Kernels deaktiviert werden kann. Das Verhalten von pr_debug () wird durch die dynamische Debug-Funktion gesteuert. Wenn CONFIG_DYNAMIC_DEBUG festgelegt ist, können alle pr_debug () -Aufrufe pro Aufrufseite dynamisch aktiviert / deaktiviert werden. Das Detail des dynamischen Debuggens finden Sie hier . Wenn CONFIG_DYNAMIC_DEBUG nicht festgelegt ist, DEBUG jedoch in der Quelldatei definiert ist, funktioniert pr_debug () wie printk () . Wenn beide nicht definiert sind, führt pr_debug nichts aus.

Hier ist die Definition im Kernel:

#include <linux/dynamic_debug.h>

/* If you are writing a driver, please use dev_dbg instead */
#if defined(CONFIG_DYNAMIC_DEBUG)
/* dynamic_pr_debug() uses pr_fmt() internally so we don't need it here */
#define pr_debug(fmt, ...) \
    dynamic_pr_debug(fmt, ##__VA_ARGS__)
#elif defined(DEBUG)
#define pr_debug(fmt, ...) \
    printk(KERN_DEBUG pr_fmt(fmt), ##__VA_ARGS__)
#else
#define pr_debug(fmt, ...) \
    no_printk(KERN_DEBUG pr_fmt(fmt), ##__VA_ARGS__)
#endif

Überprüfen Sie also Ihre Kernelkonfiguration und finden Sie heraus, woher diese Protokolle stammen. Dann wissen Sie, wie Sie es deaktivieren können.

Neben der Einstellung von loglevelaus der KCL können Sie auch die kernel.printkSystemsteuerung so anpassen , dass die maximale Stufe Ihren Wünschen entspricht und auch beim Booten erhalten bleibt.

Zu dieser weiteren Klarstellung im Kommentar:

Das Problem ist, dass Syslog und Dmesg mit nutzlosen Debugging-Protokollen überflutet werden, wodurch echte Warnungen und Fehler leichter übersehen werden können.

Ich würde nur logrotatein einem Cron-Job verwenden, um die Dateien nach dem Neustart aus dem Weg zu räumen :

root ~ $ crontab -l
@reboot /usr/sbin/logrotate --force /root/rotate-boot-messages
@reboot /bin/dmesg -c

root ~ $ cat /root/rotate-boot-messages
"/var/log/dmesg" {
  copytruncate
  notifempty
  missingok
  dateext
}
"/var/log/syslog" {
  copytruncate
  notifempty
  missingok
  dateext
}

Dann fangen Sie sozusagen neu an, mit begrenztem Debug-Daten-Dumping in Protokollen.