watchdog: comportamento das opções de arquivo e sincronização?

Question

Aqui está minha situação:

Estou tendo um problema muito ocasional em que um sistema PC / 104 embutido remoto rodando Debian parece perder a habilidade de usar qualquer interface de comunicação. Não consigo acessá-lo via portas ethernet ou serial (o console). Depois de ligar a energia, os registros do sistema não mostram nada de errado. Eles acabam abruptamente e voltam minutos ou horas depois, quando eu faço o ciclo.

Suspeito que o sistema não esteja bloqueado, porque tenho um script python que tenta acessar o google.com e, se ele falhar, ele usa um PIN de IO para alternar a fonte de alimentação do modem sem fio por meio de um relé.

Então, eu tenho um sistema completamente sem resposta, e um modem que está sendo desligado a cada dez minutos pelo mesmo sistema. Felizmente, entre as reinicializações, posso usar o modem para ligar e desligar o processador. E volte e colete dados.

O sistema tem um watchdog de hardware e eu tive a configuração watchdogd e rodando por um tempo. Na última vez que isso aconteceu, tentei adicionar a linha:

file=/var/log/messages

para watchdog.conf, mas isso não ajudou. Eu li então que

When using file mode watchdog will try to stat(2) the given files. Errors returned by stat will not cause a reboot. For a reboot the stat call has to last at least one minute.

Eu não sei o suficiente sobre stat para saber como ele pode responder a perder a capacidade de gravar em disco, mas suspeito que ele não seja interrompido.

Eu também notei que o watchdogd tem uma opção --sync, mas as páginas do manual não são muito detalhadas sobre o que acontece se a sincronização falhar. Meu intervalo é de 2 segundos, existem motivos para não sincronizar um SSD a cada dois segundos?

-Obrigado

    

Answer 1

O que você quer dizer com "se a sincronização falhar"? Man page for sync (2) diz sobre os códigos de retorno "sync () é sempre bem sucedido". Então, apenas uma maneira de "falhar" no seu caso é que ele não retorna o controle para watchdogd rápido o suficiente (porque muitos blocos para escrever, gravação lenta, disco quebrado ou corrompido ou sistema de arquivos ou camada de E / S do kernel, ... )

E se ele não devolver o controle ao watchdogd rápido o suficiente, ele não poderá gravar em / dev / watchdog em breve, e seu watchdog de hardware deve acionar a reinicialização do hardware.

stat (2) pode ter problema com o disco não gravável somente se o erro for desse tipo para evitar a leitura (bug do kernel, camada de E / S corrompida). E sim, poderia ser suspenso se houvesse um problema ali. BTW, você deve usar "file = / var / log / messages" em combinação com "change=" para que o watchdog inicie a reinicialização se o arquivo não for alterado com freqüência suficiente.

Quanto ao watchdog, você tem certeza absoluta de que o watchdog de hardware está funcionando? você modprobe o módulo de hardware correto antes de iniciar o watchdogd? O dmesg (8) indica isso? Se você "KILL -STOP" watchdogd processo, a máquina deve reiniciar. Em caso afirmativo, você pode tentar adicionar a opção "nowayout" ao seu módulo de hardware para eliminar a chance de, por exemplo, killer do OOM matar watchdogd e parar o watchdog de hardware. Você também pode adicionar "test-binary" e "test-timeout" para executar um script personalizado que retornaria se o sistema fosse considerado ativo ou não (e iniciasse a reinicialização se não fosse).