Como impedir que mensagens do kernel inundem meu console?


45

Estou usando o Centos 6, log de rsyslog. O console é inundado com mensagens do kernel.

  • O Klogd não está funcionando (estou usando o rsyslog)
  • A configuração do Rsyslog não direciona nada para o console
  • Até tentou parar o rsyslog completamente

Ainda algo está inundando meu console com mensagens de log do kernel. O que é e como faço para parar?

Atualização : Estas são as mensagens geradas pelo kernel (hardware, iptables, etc.), coisas que saem /proc/kmsgassim:

Shorewall: pub2loc: GOTA: IN = br0 OUT = MAC = xxx SRC = xxx DST = xxx LEN = 60 TOS = 0x00 PREC = 0x00 TTL = 128 ID = 15731 PROTO DF = TCP SPT = 63767 DPT = 3493 WINDOW = 8192 RES = 0x00 SYN URGP = 0


Como são as mensagens? (Pessoalmente, geralmente trabalho em uma xtermjanela, por isso, se o console estiver inundado, isso não me incomoda.) #
Keith Thompson

Correndo o risco de afirmar o óbvio, as mensagens vêm de Shorewall (que eu nunca usei, então não posso ajudar muito). Adicionar uma tag shorewall ou firewall pode receber uma atenção mais útil.
Keith Thompson.

@ KeithThompson: as mensagens estão chegando através do mecanismo de registro do kernel. O Shorewall é apenas um produtor dessas mensagens (via módulos do kernel do iptables), o mais irritante, mas todas as mensagens geradas pelo kernel são mostradas lá.
haimg

Respostas:


27

Eu sugiro que você altere o seu /etc/sysctl.conf. Especificamente, você deseja ajustar a linha kernel.printk .

# Uncomment the following to stop low-level messages on console
kernel.printk = 3 4 1 3

Não tenho certeza de quais são as configurações padrão do centos, mas parece provável que as coisas sejam definidas com mais detalhes do que você precisa.

Veja também a seção shorewall no registro. Você não precisa usar o destino LOG para fazer logon, pode usar outras ferramentas ou ajustar a gravidade do log e ajustar as coisas para controlar para onde as mensagens vão.


32

Para definir os valores em tempo de execução, use sysctl. (Suponho que se possa escrever /proc/sys/kernel/printkdiretamente também e, aparentemente, você também pode usar dmesg -n CURcomo descrito aqui )

Exibição:

# sysctl kernel.printk
kernel.printk = 2       4       1       7

Os separadores na saída são guias únicas, btw.

Conjunto. Aqui os separadores são apenas espaços. Funciona também.

# sysctl -w kernel.printk="2 4 1 7"
kernel.printk = 2 4 1 7
# sysctl kernel.printk
kernel.printk = 2       4       1       7

Veja man sysctl- "configurar parâmetros do kernel em tempo de execução" para mais.

Lembrete dos níveis de gravidade e dos quatro valores de kernel.printk fornecidos por Brian acima:

  • CUR = nível de gravidade atual; apenas mensagens mais importantes que este nível são impressas
  • DEF = nível de gravidade padrão atribuído a mensagens sem nível
  • MIN = CUR mínimo permitido
  • BTDEF = CUR padrão no momento da inicialização

No meu CentOS: 7 4 1 7

                     CUR  DEF  MIN  BTDEF
0 - emergency        x              x                        
1 - alert            x         x    x
2 - critical         x              x
3 - error            x              x
4 - warning          x    x         x
5 - notice           x              x
6 - informational    V              V
7 - debug            

Isso é muito barulhento, eu só quero críticas e até (sem erros). Mensagens sem rótulo devem ser consideradas como aviso, portanto a DEF é boa:

                     CUR  DEF  MIN  BTDEF
0 - emergency        x              x                        
1 - alert            x         x    x
2 - critical         x              x
3 - error            V              V
4 - warning               x         
5 - notice                           
6 - informational                   
7 - debug            

Defina para: 3 4 1 3


4
man klogctltambém explica os níveis.
Ciro Santilli # 13/17

12

Achei isso útil também. Nas distros baseadas em RHEL, você pode cat /proc/sys/kernel/printkver quais são suas configurações atuais.

Quatro valores são encontrados no arquivo printk. Cada um desses valores define uma regra diferente para lidar com mensagens de erro. O primeiro valor, chamado de nível de log do console, define a menor prioridade das mensagens impressas no console. (Observe que, quanto menor a prioridade, maior o número do nível de log.) O segundo valor define o nível de log padrão para mensagens sem um nível de log explícito anexado a elas. O terceiro valor define a configuração de nível de log mais baixa possível para o nível de log do console. O último valor define o valor padrão para o nível de log do console.

O uso do parâmetro LOGLEVEL em / etc / sysconfig / init para definir o nível de log do console não é mais suportado. Para definir o nível de log do console no Red Hat Enterprise Linux 6, passe loglevel = 'como um parâmetro de tempo de inicialização. Por exemplo, loglevel = 6 imprimirá todas as mensagens menores que 6 (não iguais a apenas menores que).

Crédito para:


6

Aqui está a maneira "oficial" de fazê-lo, de acordo com o RedHat :

Para definir o nível de log do console no Red Hat Enterprise Linux 6, passe loglevel = <number> como um parâmetro de tempo de inicialização.



0

O que você vê são mensagens de log do kernel impressas no console. Quais mensagens de log atingem o console dependem do nível de log do console definido atualmente.

Quando o cmdline do kernel inclui o quietparâmetro kernel, o nível de log do console resultante é 4(erros ou pior). Sem ele, é definido como 7(ou seja, informações e coisas piores).

Você pode visualizar os parâmetros ativos do kernel cat /proc/cmdlinee o nível de log atual do console sysctl kernel.printk. Pode ser alterado dinamicamente com dmesg -n X(ou mesmo com sysctl -w).

Para tornar a alteração permanente, você pode adicionar parâmetros do kernel ao cmdline do kernel (por exemplo, quiete / ou loglevel=X) ou adicionar um .confarquivo sysctl em /etc/sysctl.d.

O parâmetro kernel pode ser adicionado assim:

# vi /etc/default/grub # edit the GRUB_CMDLINE_LINUX value
# for i in /boot/grub2/grub.cfg /boot/efi/EFI/*/grub.cfg; do
     [ -f "$i" ] && grub2-mkconfig -o "$i" ; done

0

Como este é um site relacionado ao estouro de pilha, começarei dizendo que você não deve desligar a saída, que deve resolver os erros.

Se você estiver em um console e não conseguir nem ver o que está fazendo por causa das mensagens, tente digitar isso.

sudo dmesg -D

Isso deve torná-lo silencioso o suficiente para analisar as outras soluções.


-1

Se você estiver em um congestionamento real, basta desabilitar temporariamente o serviço syslog caso haja uma inundação que não consiga visualizar ou digitar qualquer coisa corretamente.


A pergunta diz que parar o daemon syslog já foi tentado, e isso não é suficiente
Toby Speight
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.