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.