rsyslog preenchendo / var / log coloca o sistema inativo

6

Por vezes, um processo corre mal e os registos em /var/log crescem tanto que acabam por encher toda a partição.

Ocorreu-me uma vez em um servidor devido a uma configuração incorreta do postfix e uma vez em um desktop devido a uma impressora USB (não sei exatamente o que deu errado, tudo que sei são os logs preenchidos com (hp) did not claim interface 1 before use ). / p>

Eu sei que a causa raiz não é o registrador, mas o aplicativo. No entanto, não posso deixar de pensar que este ponto fraco é uma vergonha. Especialmente em uma área de trabalho, onde uma impressora que preenche toda a partição do sistema impede que o usuário carregue a GUI na próxima execução (sem espaço em /tmp ), que é um bloqueador total para uma não-techy.

  • logrotate não é uma resposta porque atua diariamente ou até mesmo semanalmente.

  • rsyslog tem esse tamanho máximo, ação no tamanho máximo config opção, mas parece não trivial e de acordo com o documento em si, pode quebrar em uma versão futura.

  • Colocar /var/log em uma partição dedicada, no entanto, impediria que isso acontecesse.

Pelo que sei, a partição separada para /var/log é a única solução para isso. Eu vi isso recomendado algumas vezes, mas não é o padrão no instalador do Debian, por exemplo. Deveria ser?

Existe alguma outra maneira simples de evitar isso? Alguma maneira de fornecer um tamanho máximo para o diretório /var/log , ou pelo menos para rsyslog ?

Este problema não é freqüente o suficiente para justificar um mecanismo de proteção que seria ativado por padrão? (Eu estou particularmente pensando em instalação em casa / desktop, para o qual os usuários não devem ser capazes de lidar com isso sozinhos.)

Editar: SystemLogRateLimit

Graças a resposta de Julie Pelletier , descobri o mecanismo de limite de taxa no rsyslog que responde precisamente a essa necessidade e deve ser ativado por padrão.

There is input rate limiting available, (since 5.7.1) to guard you against the problems of a wild running logging process. If more than SysSock.RateLimit.Interval * SysSock.RateLimit.Burst log messages are emitted from the same process, those messages with SysSock.RateLimit.Severity or lower will be dropped.

No entanto, SystemLogRateLimit não funciona se o PID for alterado. A página do documento explica como testar o recurso de limitação de taxa e diz que

rate limiting only works if the same PID is given

Acho que é por isso que não se aplica aqui.

Na minha área de trabalho:

Jul 25 21:34:36 bouzin kernel: [46038.140491] usb 1-5: usbfs: process 12126 (hp) did not claim interface 1 before use
Jul 25 21:34:36 bouzin kernel: [46038.140546] usb 1-5: usbfs: process 12127 (hp) did not claim interface 1 before use
Jul 25 21:34:36 bouzin kernel: [46038.140606] usb 1-5: usbfs: process 12128 (hp) did not claim interface 1 before use
Jul 25 21:34:36 bouzin kernel: [46038.140675] usb 1-5: usbfs: process 12129 (hp) did not claim interface 1 before use
Jul 25 21:34:36 bouzin kernel: [46038.140740] usb 1-5: usbfs: process 12130 (hp) did not claim interface 1 before use
Jul 25 21:34:36 bouzin kernel: [46038.140809] usb 1-5: usbfs: process 12131 (hp) did not claim interface 1 before use
Jul 25 21:34:36 bouzin kernel: [46038.140868] usb 1-5: usbfs: process 12132 (hp) did not claim interface 1 before use
Jul 25 21:34:36 bouzin kernel: [46038.140928] usb 1-5: usbfs: process 12133 (hp) did not claim interface 1 before use
Jul 25 21:34:36 bouzin kernel: [46038.140988] usb 1-5: usbfs: process 12134 (hp) did not claim interface 1 before use
Jul 25 21:34:36 bouzin kernel: [46038.141046] usb 1-5: usbfs: process 12135 (hp) did not claim interface 1 before use

No meu servidor:

Jul  5 13:37:45 server postfix/smtpd[426]: NOQUEUE: reject_warning: RCPT from unknown[177.11.51.178]: 451 4.3.0 <[email protected]>: Temporary lookup failure; from=<[email protected]> to=<[email protected]> proto=ESMTP helo=<mail.SERVER.TEST>
Jul  5 13:37:45 server postfix/smtpd[437]: NOQUEUE: reject_warning: RCPT from unknown[177.11.51.178]: 451 4.3.0 <[email protected]>: Temporary lookup failure; from=<[email protected]> to=<[email protected]> proto=ESMTP helo=<mail.SERVER.TEST>
Jul  5 13:37:45 server postfix/smtpd[426]: NOQUEUE: reject_warning: RCPT from unknown[177.11.51.178]: 451 4.3.0 <[email protected]>: Temporary lookup failure; from=<[email protected]> to=<[email protected]> proto=ESMTP helo=<mail.SERVER.TEST>
Jul  5 13:37:45 server postfix/smtpd[437]: NOQUEUE: reject_warning: RCPT from unknown[177.11.51.178]: 451 4.3.0 <[email protected]>: Temporary lookup failure; from=<[email protected]> to=<[email protected]> proto=ESMTP helo=<mail.SERVER.TEST>

Portanto, o recurso de limitação de taxa do IIUC rsyslog não é relevante aqui, porque cada linha de log é escrita por um processo diferente.

Editar 2: restringir o tamanho do diretório

Acabei limitando o tamanho de /var/log usando um sistema de arquivos virtual (como sugerido aqui ).

Eu posso configurar uma partição separada da próxima vez que eu instalar um Linux.

Estou mantendo essa questão em aberto por enquanto, pois considero isso uma solução alternativa em vez de uma resposta.

    
por Jérôme 30.07.2016 / 22:26

1 resposta

5

rsyslog inclui uma opção de limitação de taxa por padrão através do módulo imuxsock .

O padrão é 200 mensagens por 5 segundos, mas pode ser facilmente alterado, definindo o seguinte após o módulo ser carregado:

$SystemLogRateLimitInterval 5
$SystemLogRateLimitBurst 200

O $SystemLogRateLimitInterval é o intervalo em segundos (que você deve aumentar) e $SystemLogRateLimitBurst é o número máximo de mensagens permitido pelo aplicativo durante esse intervalo (que você deve diminuir).

Atualização: Com base em sua atualização sobre o fato de que os erros estão inundando seu syslog com IDs de processo diferentes, não há nenhuma maneira prática de o daemon lidar com isso de forma eficiente.

Alterar as regras de rotação de log no tamanho máximo do arquivo seria, portanto, a única solução possível. Observe que, uma vez compactados (conforme o processo normal de rotação de logs), esses arquivos grandes se tornarão minúsculos devido à repetibilidade de seus conteúdos.

    
por 30.07.2016 / 22:47