Depuração lock-up - systemd perde meus logs

Question

Desde que eu "atualizei" para o systemd no Arch Linux, eu continuo perdendo logs quando um bloqueio inesperado acontece. Eu bati o mesmo problema de perda de log um mês atrás e acabei de acertar o problema novamente. Há também outras confirmações independentes .

Situação:

• Enquanto fazia algumas coisas em Java e com utilitários relacionados à rede, vi que o KDE (o relógio) estava congelado. O ventilador da CPU ficou barulhento e o calor estava aumentando. O ponteiro do mouse ainda pode ser movido.
• tentei ssh de outra máquina (falha devido a "nenhuma rota para hospedar")
• Esperei alguns minutos, talvez o watchdog da NMI pudesse matar a tarefa ofensiva. Sem dados.
• Ctrl + Alt + F1 também não funcionou, mesmo após SysRq + R
• Como as etapas acima não funcionaram, decidi emitir a sequência R-E-I do SysRq. Depois de E , a tela ficou preta, mas nenhum console também. Nem mesmo depois de SysRq + K
• Então, esta sessão parece estar perdida, a única coisa que pode ser feita é coletar informações de depuração. Olhando para Wikipedia , decidi pressionar SysRq + d ( exibir travas seguras) entre algumas outras.
• Depois de pressionar SysRq + S , esperei um segundo e, em seguida, reiniciei com SysRq + B . li>
• Após a reinicialização e o login em um console, não vi nenhum vestígio de qualquer falha. A entrada registrada mais recentemente foi de usar o Wireshark, mas ainda havia uma lacuna de 45 minutos.

(Eu estava executando o Linux v3.8-rc5-218-ga56e160 btw)

Então, como posso ter certeza de que meus logs serão mantidos quando forem reinicializados de forma anormal devido a um bloqueio?

    

Answer 1

Então eu perguntei no canal de IRC #systemd e acontece que o journald (o daemon de log do systemd) não limpa periodicamente os logs para o disco. Isso significa que seus registros estão sempre em risco a qualquer momento.

Enviar SIGUSR2 para o journald faz com que os logs sejam gravados no disco, mas se você fizer isso várias vezes, muitos arquivos serão criados. (a opção é realmente descrita como "log rotating").

No final, decidi seguir com outra sugestão: usar um daemon syslog dedicado para coletar logs do kernel. Como o rsyslog foi sugerido (e eu já tive experiência com ele), explorei essa opção ainda mais. Eu escrevi mais alguns detalhes no Arch Wiki sobre como usar o rsyslog.

A idéia é executar o rsyslog, coletando apenas dados do recurso do kernel. Como o rsyslog lê as leituras /proc/kmsg (que permite apenas um único leitor) e o journald de /dev/kmsg (múltiplos leitores permitidos), não há como os daemons perderem os logs (muito importante para mim!). Configure o rsyslog para gravar mensagens do kernel em um arquivo e certifique-se de que este arquivo seja girado para evitar que o espaço do seu disco seja gasto.

Esta solução não é perfeita:

• Outros registros (por exemplo, do NetworkManager) são perdidos. Isso poderia ser resolvido pelo encaminhamento de mais logs do syslog para o journald (isso significa duplicação!)
• Duplicação de logs. As mensagens do kernel são gravadas em dois arquivos. Este não é um problema, em geral, o número de logs é pequeno e você preferiria ter mais cópias dos logs do que nenhuma. Você também pode usar ferramentas rápidas como grep no arquivo de log único ou o mais lento, mas extravagante journalctl .

Existe um item TODO para limpar os registos com mais frequência, mas que ainda não é confiável o suficiente:

journal: send out marker messages every now and then, and immediately sync with fdatasync() afterwards, in order to have hourly guaranteed syncs.

Agora, esperamos que systemd / journald tenha uma opção para gravar os logs em disco, mas enquanto isso podemos combinar ferramentas para alcançar o objetivo.

    

Answer 2

Existem duas atualizações:

1. Agora, esperamos que systemd / journald tenha uma opção para gravar os logs para o disco, mas enquanto isso podemos combinar ferramentas para atingir o objetivo.

Existe uma opção --sync :

Asks the journal daemon to write all yet unwritten journal data to the backing file system and synchronize all journals. This call does not return until the synchronization operation is complete. This command guarantees that any log messages written before its invocation are safely stored on disk at the time it returns.

--sync disponível desde v228 :

journalctl gained a new "--sync" switch that asks the journal daemon to write all so far unwritten log messages to disk and sync the files, before returning.

2. Acontece que o journald (o daemon de log do systemd) não periodicamente liberar os logs para o disco em tudo. Isso significa que seu os logs estão sempre em risco a qualquer momento.

man journald.conf(5) diz:

SyncIntervalSec=

The timeout before synchronizing journal files to disk. After syncing, journal files are placed in the OFFLINE state. Note that syncing is unconditionally done immediately after a log message of priority CRIT, ALERT or EMERG has been logged. This setting hence applies only to messages of the levels ERR, WARNING, NOTICE, INFO, DEBUG. The default timeout is 5 minutes.

SyncIntervalSec= disponível desde v199 :

journald will now explicitly flush the journal files to disk at the latest 5min after each write. The file will then also be marked offline until the next write. This should increase reliability in case of a crash. The synchronization delay can be configured via SyncIntervalSec= in journald.conf.

Veja também:

journald: envia SIGTERM / SIGINT com baixa prioridade

Let's make sure to process all queued log data before exiting, so that we don't unnecessary lose messages when shutting down.