diminuir o nível de verbosidade do log de inicialização do kernel


9

Quando meu kernel é inicializado, além das informações importantes úteis, ele imprime muitas informações de depuração, como

....
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 muito, muito mais.

Não vejo como isso pode ser útil para alguém que não seja um desenvolvedor / depurador de kernel.

Eu descobri que posso me livrar deles usando loglevel=5como parâmetro de inicialização. Os logs de depuração não são mais impressos no terminal, mas ainda estão dentro dmesge dentro syslog.

É possível diminuir a verbosidade de registo de inicialização globalmente, para que dmesge syslognão são inundadas por esta informação inútil?

Estou usando o kernel auto compilado 3.18

SOLUÇÃO ACEITADA

Acontece que, colocando as seguintes linhas para /etc/rsyslog.confresolver o problema para mim:

kern.debug   /dev/null
& ~

Quais são os problemas que você está tentando resolver? Arquivos de log muito grandes? Perguntando, já que não vejo problema em ter essas informações em um log que geralmente não é lido por humanos e cujo tamanho é trivial.
Hennes

@Hennes - o problema é que, sysloge dmesgsão inundados com os registros de depuração inúteis, e tornando avisos reais e erros mais fáceis de ignorar. Além disso, dmesge syslogdeve ser lido por humanos (ou seja, o administrador). Esse é todo o seu propósito.
Martin Vegter

A preocupação com a inundação de informações importantes é um bom ponto.
Hennes

1
Você pode se interessar por esta pergunta no site do Superuser Stack-Exchange: Como impedir que mensagens do kernel inundem meu console?
perror

Respostas:


5

Para syslog Você pode adicionar a seguinte linha em /etc/syslog.conf:

kern.info; kern.debug   /dev/null

Ele descartará as mensagens .info e .debug do kernel (que são descartadas com loglevel = 5)

Além disso, dmesgpode ser usado com a opção -nde mostrar mensagens com determinado nível de log.


4

Alguns dos logs são impressos por printk () que você não pode desativá-lo. E alguns são impressos por pr_debug () que pode ser desativado depende da configuração do kernel. O comportamento de pr_debug () é controlado pelo recurso de depuração dinâmica. Se CONFIG_DYNAMIC_DEBUG estiver definido, todas as chamadas pr_debug () poderão ser ativadas / desativadas dinamicamente por local de chamada. Os detalhes da depuração dinâmica estão aqui . Se CONFIG_DYNAMIC_DEBUG não estiver definido, mas DEBUG estiver definido no arquivo de origem, pr_debug () funcionará como printk () . Se ambos não estiverem definidos, pr_debug não fará nada.

Aqui está a definição no 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

Portanto, verifique a configuração do seu kernel e descubra de onde vêm esses logs. Então você saberá como desativá-lo.


Também não se esqueça de echo 8 > /proc/sys/kernel/printk: stackoverflow.com/questions/28936199/...
Ciro Santilli冠状病毒审查六四事件法轮功

0

Além de definir a loglevelpartir da KCL, você também pode ajustar o kernel.printksysctl para que o nível máximo reflita o que você deseja e persista durante a inicialização.

Quanto a este esclarecimento adicional no comentário:

o problema é que o syslog e o dmesg são inundados com logs de depuração inúteis, tornando assim avisos e erros reais mais fáceis de ignorar.

Eu apenas usaria logrotateem um trabalho cron para mover os arquivos para fora do caminho após a reinicialização :

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
}

Então você está começando do zero, por assim dizer, com o despejo limitado de dados de depuração nos logs.


Sinto muito, mas sugerir logrotatecompletamente erra o ponto. Meu problema não é que meus arquivos de log sejam muito grandes e que estou ficando sem espaço em disco. Em vez disso, o problema é que as informações de depuração nesses arquivos de log tornam as informações úteis menos acessíveis.
Martin Vegter 14/10/2015

Direita. Use logrotate para mover o log com toda essa porcaria, para que você tenha um arquivo de log vazio após a inicialização, para poder ver o que importa. Meu uso do logrotate aqui não é canônico: use mv se desejar. O objetivo é resolver o problema o mais rápido possível após a inicialização.
bispo

A menos que você queira dizer que essas mensagens ocultam problemas no tempo de inicialização? Nesse caso, a solução aceita parece ideal.
bispo
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.