Rodar um log do vigia VPN sem quebrar o escritor

Uma verificação de saúde VPN que acrescenta uma linha por minuto cria silenciosamente um segundo dever: decidir como essas linhas saem do disco. Corrigir o túnel não faz nada por esse dever, e renomear o arquivo não redireciona um processo que ainda detém o descritor antigo. Responda primeiro à questão do destino e depois faça a rotação corresponder à forma como o escritor o abre.

Escolha o destino antes da política de rotação

Uma unidade systemd que já envia a sua saída para o journal mantém a retenção num só lugar. O journald impõe limites como SystemMaxUse e MaxRetentionSec , por isso um vigia que registra ali herda um limite sem trabalho extra. Acrescentar um segundo arquivo sem limite ao lado duplica a manutenção sem ganho.

Um arquivo dedicado ganha o seu lugar quando algo mais o lê: um analisador, uma exportação de auditoria ou uma página que espera um caminho estável. Uma vez tomada essa decisão, o arquivo precisa de um proprietário, de um modo e de uma política de rotação escritos em conjunto, porque os três só estão corretos como conjunto. Um caminho que qualquer um pode criar também é um caminho que qualquer um pode substituir, por isso as permissões do diretório pertencem à mesma nota. Escreva tudo isso ao lado da verificação e a próxima edição começa nos mesmos factos.

Escreva o bloco para corresponder ao escritor

Comece por um escritor que abre o caminho em cada invocação, acrescenta uma linha e sai. Esse padrão sobrevive à rotação sem qualquer cooperação do processo, porque a execução seguinte abre o arquivo que está atualmente nesse caminho. O bloco abaixo mantém uma semana de versões e recria o arquivo com o proprietário e o modo de que o escritor precisa:

/var/log/vpn-watchdog.log {
    daily
    rotate 7
    create 0600 root root
    missingok
    notifempty
}

O manual do logrotate define a contagem como o número de versões rodadas mantidas, não como uma garantia de sete dias de histórico, e a palavra-chave daily é avaliada quando a tarefa corre em vez de atuar como o seu próprio agendador. Na maioria das distribuições, um temporizador systemd ou uma entrada cron já detém essa invocação, por isso verifique qual existe antes de acrescentar uma segunda. Acertar na propriedade importa mais do que a contagem de retenção. Copiar um modo só para root para um arquivo escrito por uma conta de serviço pára o registo na rotação seguinte, e a falha aparece horas depois como um carimbo de data obsoleto em vez de como um erro. Confirme o utilizador do escritor antes de copiar um bloco de outro sítio.

Um escritor que nunca reabre precisa de outra solução

Um processo de longa duração que detém um descritor aberto continua a escrever no inode renomeado. O espaço não é libertado e o arquivo visível deixa de crescer, o que parece uma rotação quebrada até verificar o inode. Ou ensine o processo a reabrir, ou faça a rotação copiar e truncar em vez de renomear.

O caminho da reabertura é o mais limpo onde o software o suporta: envie o sinal documentado ou execute o comando documentado, e deixe o processo abrir ele mesmo o novo arquivo. A alternativa é copytruncate , que copia o conteúdo para o nome rodado e depois trunca o original no lugar, de modo que o descritor continua válido mas as escritas que caem entre a cópia e o truncamento perdem-se.

Para unidades iniciadas pelo systemd, aponte StandardOutput para o journal ou para um arquivo e deixe a unidade deter o ciclo de vida. Um ciclo shell que acrescenta através de tee -a sem limite de tamanho é a disposição que enche uma partição durante uma falha, porque uma verificação falhada regista muitas vezes muito mais do que uma saudável.

Teste a rotação sem esperar pelo temporizador

O modo de depuração relata o que aconteceria e não toca em nada, o que o torna a primeira execução segura após uma edição. Força uma rotação real quando estiver satisfeito e depois confirme que a linha de registo seguinte cai no arquivo novo e não no renomeado:

logrotate -d /etc/logrotate.d/vpn-watchdog
logrotate -f /etc/logrotate.d/vpn-watchdog
ls -l /var/log/vpn-watchdog.log*
tail -n 3 /var/log/vpn-watchdog.log
df -h /var/log

Leia a saída nessa ordem. A passagem de depuração deve nomear o arquivo e as ações que pretende; uma execução forçada deve produzir o nome rodado esperado; a cauda deve mostrar uma entrada nova depois de o escritor voltar a correr. Um valor df crescente com um arquivo visível a encolher significa o problema de descritor descrito acima.

Repita a execução forçada duas vezes para ver como a retenção se comporta quando já existem versões. Apagar o arquivo mais antigo é o resultado esperado, e uma eliminação ausente normalmente significa que a contagem ou o curinga no nome rodado não coincide com o que o logrotate criou.

Guarde uma reversão e um registo escrito

Guarde o bloco anterior antes de editar e anote que agendador o executa, porque uma reversão que restaura o arquivo mas não o temporizador reproduz metade do problema original. Rode uma vez à mão depois de restaurar e depois confirme que a conta do escritor pode escrever no caminho do registo. Se o serviço correr sob systemd, recarregue a unidade após qualquer alteração no redirecionamento da sua saída, porque o processo em execução continua a escrever no alvo antigo. Leia você mesmo as linhas de registo seguintes em vez de confiar que a unidade voltou limpa.

Registe o modo, o proprietário, a contagem de retenção e o orçamento de disco esperado ao lado da própria verificação. Quando mais tarde a verificação passar de um script de uma só vez para um daemon, a política de rotação tem de mudar com ela, e essa nota é o que diz à pessoa seguinte que suposição se quebrou.

Por fim, mantenha a decisão do registo separada da decisão de recuperação. Uma verificação falhada deve seguir a política de recuperação da própria ligação, não uma regra escondida dentro do logrotate, e nenhuma disposição de registo deve ser a razão para reiniciar um túnel que funciona.