Redirecionando mensagens de erro syslogd para um log de erros ou para um arquivo nulo?

2

Eu tenho um antigo laptop PowerPC (antigo Mac Powerbook G4) que estou executando uma variante do Debian Squeeze on (MintPPC 9).

Continuo recebendo mensagens de erro do Kernel quando estou conectado a uma rede sem fio específica, mas não em outras ocasiões. Eu suspeito, mas não provei, que está surgindo do módulo de rede. As mensagens de erro sobrecarregam qualquer coisa que eu esteja fazendo no momento (por exemplo, sobrepondo uma tela do CLI Emacs), mas de outra forma não parecem influenciar a função da máquina, até mesmo a rede parece estar se recuperando.

Existe uma maneira de redirecionar mensagens de erro do syslogd especificamente para um log de erros ou, possivelmente, /dev/null , mas para deixar outras mensagens de erro indo para stdout . Eu sei que 2>> direcionará mensagens de erro, mas como eu não iniciei conscientemente o syslogd, não sei como fazer isso.

Às vezes, as mensagens de erro são mais elaboradas, mas aqui está um exemplo:

Message form syslogd@debian at Dec 10 09:48:02 ...
 kernel:[   720.749515] -----------[  cut here  ]---------------
    
por haziz 10.12.2012 / 15:37

1 resposta

3

O que você está enfrentando é uma mensagem wall ed .

O daemon syslog padrão do Debian, rsyslog , enviará com a configuração padrão mensagens com gravidade emerg de qualquer facilidade ( * ) para todos os usuários conectados , via wall (de /etc/rsyslog.conf ):

#
# Emergencies are sent to everybody logged in.
#
*.emerg                         :omusrmsg:*

Você pode alterar isso configurando o Rsyslog para fazer outra coisa.

Por exemplo (embora não tenha certeza se é realmente aconselhável tornar as mensagens de emergência ignoráveis), você pode alterar a regra /var/log/messages pega-tudo (acima de *.emerg )

*.=info;*.=notice;*.=warn;\
        auth,authpriv.none;\
        cron,daemon.none;\
        mail,news.none          -/var/log/messages

para também capturar *.emerg e comentar a regra abaixo.

(Espero que isso ajude você, tenho que admitir que não segui completamente o seu parágrafo sobre o redirecionamento do stdout ...)

    
por 10.12.2012 / 16:13