ridurre il livello di verbosità del registro di avvio del kernel


9

Quando il mio kernel si avvia, oltre alle utili informazioni importanti, stampa molte informazioni di debug, come

....
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)

e molto altro ancora.

Non vedo come questo possa essere utile a chiunque diverso da uno sviluppatore / debugger del kernel.

Ho scoperto che posso sbarazzarmi di questi usando loglevel=5come parametro di avvio. I log di debug non vengono più stampati sul terminale, ma sono ancora dentro dmesge dentro syslog.

E 'possibile diminuire il livello di dettaglio del registro di avvio a livello globale, in modo che dmesge syslognon sono invaso da queste informazioni inutili?

Sto usando il kernel autocompilato 3.18

SOLUZIONE ACCETTATA

Si scopre, mettendo le seguenti righe per /etc/rsyslog.confrisolvere il problema per me:

kern.debug   /dev/null
& ~

Quali sono i problemi che stai cercando di risolvere? File di registro troppo grandi? Chiedendo poiché non vedo alcun problema con queste informazioni in un registro che di solito non viene letto dagli umani e il cui aumento delle dimensioni è banale.
Hennes,

@Hennes - il problema è, che sysloge dmesgsono inondati con i registri di debug inutili, e così facendo gli avvisi reali e gli errori più facili da trascurare. Inoltre, dmesge syslogdovrebbe essere letto dagli umani (cioè l'amministratore). Questo è il loro intero scopo.
Martin Vegter,

La preoccupazione per l'inondazione di informazioni importanti è un buon punto.
Hennes,

1
Potresti essere interessato a questa domanda sul sito Web Super-Stack Stack-Exchange: come impedire ai messaggi del kernel di inondare la mia console?
perror

Risposte:


5

Per syslog È possibile aggiungere la seguente riga a /etc/syslog.conf:

kern.info; kern.debug   /dev/null

Scarterà i messaggi kernel .info e .debug (che vengono scartati con loglevel = 5)

Inoltre, dmesgpuò essere utilizzato con l'opzione -nper mostrare i messaggi con un determinato livello di Google.


4

Alcuni registri sono stampati da printk () che non è stato possibile disattivare. E alcuni sono stampati da pr_debug () che può essere disattivato dipende dalla configurazione del kernel. Il comportamento di pr_debug () è controllato dalla funzione di debug dinamico. Se è impostato CONFIG_DYNAMIC_DEBUG , tutte le chiamate pr_debug () possono essere abilitate / disabilitate dinamicamente per ciascun sito. Il dettaglio del debug dinamico è qui . Se CONFIG_DYNAMIC_DEBUG non è impostato, ma DEBUG è definito nel file di origine, pr_debug () funziona come printk () . Se entrambi non sono definiti, pr_debug non farà nulla.

Ecco la definizione nel 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

Quindi, controlla la configurazione del tuo kernel e trova da dove provengono questi log. Quindi saprai come disabilitarlo.


Inoltre, non dimenticare di echo 8 > /proc/sys/kernel/printk: stackoverflow.com/questions/28936199/...
Ciro Santilli冠状病毒审查六四事件法轮功

0

Oltre a impostare il loglevelda KCL, puoi anche modificare il kernel.printksysctl in modo che il livello massimo rifletta ciò che desideri e persista durante l'avvio.

Per quanto riguarda questo ulteriore chiarimento nel commento:

il problema è che syslog e dmesg sono inondati di log di debug inutili, rendendo così più facile trascurare avvisi ed errori reali.

Userei semplicemente logrotatein un lavoro cron per spostare i file di mezzo dopo il riavvio :

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
}

Quindi stai ricominciando, per così dire, con i dati di debug limitati a scaricare nei log.


Mi dispiace, ma suggerendo che non ci si logrotateaccorga del tutto. Il mio problema non è che i miei file di log sono troppo grandi e che sto esaurendo lo spazio su disco. Al contrario, il problema è che le informazioni di debug in questi file di registro rendono le informazioni utili meno accessibili.
Martin Vegter,

Giusto. Usa logrotate per spostare il registro con tutto quello che ti fa impazzire, in modo da avere un file di registro vuoto dopo l'avvio, in modo da poter vedere ciò che conta. Il mio uso di logrotate qui non è canonico: usa mv se vuoi. Il punto è quello di togliere la merda il più presto possibile dopo l'avvio.
vescovo,

A meno che tu non intenda questi messaggi oscuri problemi di avvio? Nel qual caso, la soluzione accettata sembra ideale.
vescovo,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.