O ZimaCube desaparece da rede: bloqueio ou falha da placa de rede?

Em suma: primeiro determine se o ZimaCube perdeu a ligação à rede ou se todo o sistema operativo bloqueou

“Desapareceu do router” parece indicar um problema da placa de rede, mas a discussão acabou por fornecer uma pista mais forte: com um monitor e um teclado ligados, o ecrã estava visível, mas a máquina não respondia à introdução pelo teclado. Trata-se de um bloqueio do sistema, não apenas da ausência de uma concessão DHCP. A resolução de problemas muda completamente quando se faz essa distinção.

Utilize uma consola local antes da próxima falha

Deixe temporariamente um monitor e um teclado ligados. Quando o acesso remoto deixar de funcionar, teste a consola antes de desligar e voltar a ligar a alimentação. Experimente as teclas da consola do ZimaOS e verifique se o ecrã é atualizado ou se aceita introdução.

Se a introdução local funcionar, mas o router deixar de listar o dispositivo, concentre-se na Ethernet, no DHCP e no serviço de rede. Se a introdução local também não funcionar, capture o ecrã e trate o incidente como um bloqueio do sistema operativo, do kernel ou do hardware.

Use o uptime para distinguir um reinício de um bloqueio

uptime
last -x | head
journalctl -b -1 -p warning..alert
journalctl -b -1 -k

Após a recuperação, o uptime indica se o servidor foi realmente reiniciado. Os registos do arranque anterior podem revelar falhas do kernel, tempos limite de armazenamento, encerramentos por falta de memória ou erros de controladores antes do corte forçado da alimentação. Os registos do arranque anterior abrangem a seleção do arranque no journal.

Não assuma que o horário noturno do router é a causa principal

Vários utilizadores desativaram os horários do Wi-Fi ou os reinícios do router e, ainda assim, conseguiram reproduzir a falha. Isto torna insuficiente a explicação de que “o router desliga o Wi-Fi”. O servidor estava ligado por cabo e os incidentes posteriores também ocorreram durante o dia. Mantenha os eventos do router na cronologia, mas exija uma correlação reproduzível antes de os culpar.

Verifique o estado atual da Ethernet após a recuperação

ip addr
ip route
ethtool YOUR_INTERFACE
dmesg | grep -i -E 'link|ether|nic|reset|timeout'

O ZimaOS atual apresenta separadamente o estado da ligação Ethernet física, a velocidade negociada e o IP atribuído. Se o próximo incidente ocorrer apenas na rede, compare o estado da porta no router com o estado da interface local. As interfaces de rede do ZimaOS disponibilizam os controlos de rede atuais.

Se a consola ainda aceitar comandos durante um incidente limitado à rede, o ethtool pode apresentar o estado da ligação, a velocidade negociada e informações do controlador sem reiniciar. As verificações de rede do ethtool ajudam a distinguir um sistema operativo ativo com a ligação interrompida de um bloqueio completo da máquina.

Não utilize reinícios forçados repetidos como método normal de recuperação

Premir o botão de alimentação várias vezes por dia aumenta o risco de danos no sistema de ficheiros e na base de dados, especialmente durante transferências grandes ou atividade de RAID. Se a consola estiver bloqueada e não houver uma forma de encerramento normal, poderá ser inevitável efetuar um ciclo de alimentação forçado — mas, sempre que possível, recolha provas antes de o fazer.

A cópia de segurança do ZimaOS é especialmente importante durante o diagnóstico de bloqueios intermitentes do sistema.

Reduza as variáveis durante o teste de estabilidade

Pare temporariamente as aplicações não essenciais, desative dispositivos USB/PCIe desnecessários, mantenha uma única ligação Ethernet conhecida como funcional e evite migrações simultâneas de vários terabytes. Se o bloqueio desaparecer, reintroduza as cargas de trabalho uma de cada vez. Isto é muito mais informativo do que alterar simultaneamente as definições do router, do cliente, do armazenamento e das aplicações.

A recuperação do ZimaOS fornece o limite atual de recuperação do sistema caso os testes de estabilidade revelem uma partição do sistema ou uma instalação defeituosa.

Os relatórios históricos da versão 1.2.x não devem ser aplicados diretamente ao ZimaOS 1.7

O tópico é de 2024 e a IceWhale estava a corrigir ativamente casos de instabilidade na linha 1.2.x. O ZimaOS atual passou por muitas alterações no kernel, na rede, na memória, no armazenamento e nos serviços de ficheiros. Utilize o tópico para aprender o método de diagnóstico — consola versus rede, reinício versus bloqueio, registos versus suposições — e não para afirmar que todas as desconexões noturnas modernas correspondem ao mesmo erro de 2024.

Quando suspeitar de problemas de hardware

Se uma versão estável atual continuar a bloquear com um número mínimo de aplicações e armazenamento/rede comprovadamente funcionais, execute diagnósticos à memória e verifique as temperaturas, a alimentação, os dispositivos PCIe e os erros dos discos/controladores. Um bloqueio completo e reproduzível em diferentes condições de sistema operativo e rede pode levar a investigação para além do próprio ZimaOS.

A plataforma ZimaCube 2 é útil para distinguir uma caixa de hardware ZimaCube original de plataformas posteriores.

Perguntas frequentes

Porque é que o ZimaCube desaparece do meu router?

Pode tratar-se de uma falha apenas de rede, de um reinício ou de um bloqueio completo do sistema. Teste a consola local e os registos do arranque anterior antes de decidir qual é o caso.

O modo de suspensão dos discos pode fazer com que todo o ZimaCube desapareça?

Não se deve presumir que o modo de suspensão dos discos suspende todo o servidor. Se a entrada do teclado e a rede pararem simultaneamente, diagnostique antes um bloqueio completo do sistema.

Devo agendar um reinício todas as noites?

Um reinício agendado pode ocultar uma instabilidade, mas não identifica a causa. Utilize os registos e testes controlados antes de tornar o reinício a solução permanente.

O que devo recolher antes de forçar a reposição?

Fotografe a consola, teste a resposta do teclado, registe o estado da ligação ao router/DHCP, anote a hora e, após reiniciar, recolha os registos do kernel e de avisos do arranque anterior.

As transferências de ficheiros grandes podem causar o bloqueio?

Podem revelar problemas de armazenamento, memória, controladores ou temperatura, mas a transferência em si não é uma causa principal sem registos que o comprovem. Reproduza o problema com cargas de trabalho controladas.