Entendo que a revista do systemd não pode reparar ou corrigir erros revelados por:
journalctl --verify
Aqui está um exemplo de erro que acabei de ver. Eu costumo ver erros como esse em todos os dispositivos que eu gerencio.
FAIL: /var/log/journal/487de3ee24374fe3a1130c6f02b29c1c/[email protected]~ (Bad message)
391de0: Invalid entry item (30/31 offset: 000000
391de0: Invalid object contents: Bad message
File corruption detected at /var/log/journal/487de3ee24374fe3a1130c6f02b29c1c/[email protected]~:391de0 (of 8388608 bytes, 44%).
Se meu entendimento estiver correto, a única solução é:
rm /var/log/journal/487de3ee24374fe3a1130c6f02b29c1c/[email protected]~
Se for verdade, existe uma ferramenta ou script que simplesmente fará isso automaticamente? O dispositivo que acabei de verificar tinha 5 desses arquivos que eu tinha que deletar. Eu gosto de executar minha manutenção em um script automatizado, mas com isso sendo um problema tão comum, eu não quero reinventar a roda. Então, o que os outros estão fazendo? Certamente alguém já automatizou isso. Se não, meu primeiro pensamento é ao longo destas linhas:
journalctl --verify | grep 'File corruption detected at ' | ??? | xargs rm
No entanto, isso não funciona (mesmo antes de chegar ao passo com "???").