Porque é que o Immich se comporta de forma diferente depois de reiniciar um contentor?

O Immich muda depois de um reinício porque as caches temporárias desaparecem e as dependências dos serviços voltam a ligar-se, enquanto uma persistência mal configurada pode expor perdas de estado mais graves.

Uma primeira pesquisa lenta pode ser um comportamento normal de arranque a frio; um ecrã de integração inicial novo não é. Classifique o sintoma pela duração e pelo âmbito antes de alterar dados, porque o aquecimento da cache, uma falha de dependência e a ausência de armazenamento persistente exigem respostas completamente diferentes.

Um Reinício Remove o Estado Temporário do Processo

Os processos reiniciados perdem modelos em memória, conjuntos de ligações, caminhos compilados e caches da aplicação. A cache de páginas do anfitrião pode sobreviver ao reinício de um contentor, mas um reinício do anfitrião elimina ainda mais desse aquecimento. Consequentemente, o primeiro pedido de pesquisa ou da cronologia pode executar trabalho de inicialização que as repetições imediatas evitam.

Uma medição da comunidade relata uma primeira pesquisa inteligente lenta, seguida de repetições muito mais rápidas enquanto o modelo de aprendizagem automática é carregado para a memória da GPU. O tempo exato depende desse servidor, mas a transição de estado explica por que razão um único pedido após o reinício não pode representar o funcionamento estável.

Execute o mesmo pedido conhecido três vezes e registe se a latência converge. Se apenas o primeiro pedido for lento e os resultados continuarem corretos, investigue o carregamento a frio ou a política de retenção. Se todos os pedidos falharem ou parecer faltar estado, deixe de tratar o sintoma como aquecimento da cache e examine as dependências e a persistência.

A Ordem das Dependências Pode Expor uma Condição de Corrida no Arranque

O Immich depende de mais do que o processo exposto na Web. A base de dados, a coordenação das tarefas, o serviço de aprendizagem automática e os suportes de dados montados têm de ficar acessíveis com uma configuração compatível. Um contentor marcado como em execução pode ainda estar a inicializar, pelo que um pedido inicial pode falhar mesmo que a pilha fique saudável alguns instantes depois.

Um relato de falha após um reinício descreve o Immich a perder o acesso ao PostgreSQL ou ao Redis depois de alterações aparentemente não relacionadas no Compose. Esse relato não comprova um defeito generalizado do produto, mas ilustra o valor diagnóstico de relacionar os erros de ligação da aplicação com a disponibilidade das dependências e o momento do reinício.

Recolha registos com marcação temporal da aplicação e da dependência identificada durante o mesmo reinício. Verifique a resolução de DNS, a acessibilidade das portas, as verificações de estado e a disponibilidade dos suportes montados dentro do contentor. Se as tentativas automáticas recuperarem o serviço, melhore o tratamento da disponibilidade; se nunca recuperar, teste diretamente a configuração e as credenciais.

O Estado Persistente Tem de Sobreviver à Substituição do Contentor

As imagens e os ficheiros da base de dados armazenados apenas numa camada de escrita do contentor desaparecem quando esse contentor é substituído. Os volumes nomeados e os mounts de ligação só persistem quando a implementação referencia a mesma localização subjacente. Um simples reinício normalmente preserva esses dados, mas edições no Compose ou alterações de caminho podem selecionar silenciosamente um armazenamento novo e vazio.

O artigo sobre o caminho de dados da ZimaSpace explica que um caminho visível dentro do contentor não revela o armazenamento físico nem o domínio de falha por trás dele. Isto é crucial após uma recriação: um caminho interno idêntico pode apontar para um diretório diferente no anfitrião, um volume vazio ou um mount de rede indisponível.

Se o Immich apresentar a integração inicial, não crie imediatamente uma biblioteca de substituição. Inspecione os mounts efetivos, os identificadores dos volumes, a propriedade e os registos da base de dados; depois compare-os com a última implementação funcional. Novas gravações podem complicar a recuperação ao criar um segundo conjunto de estado ao lado do original em falta.

-15% OFF

ZimaBoard 2 - Mini Servidor Doméstico para a Sua Grande Ideia

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Use uma Classificação do Reinício em Cinco Minutos

No minuto zero, registe quais os contentores que foram reiniciados e se houve alterações nas imagens ou na configuração. No minuto um, verifique o estado das dependências e dos mounts. No minuto três, repita uma pesquisa conhecida e uma transferência original. No minuto cinco, decida se o comportamento está a melhorar, se continua indisponível ou se apresenta um estado vazio.

Um relato sobre a persistência da base de dados descreve a apresentação repetida da integração inicial após reinícios do Compose, enquanto o diretório esperado da base de dados no anfitrião permanecia vazio. É um único ambiente, mas fornece uma assinatura de falha clara: o desaparecimento da identidade persistente da aplicação entre reinícios indica que a base de dados está a ser escrita noutro local que não o caminho persistente pretendido.

Associe a melhoria da latência ao estado a frio, os erros de ligação ao arranque das dependências, os ficheiros multimédia em falta aos mounts e os utilizadores ou álbuns perdidos à persistência da base de dados. Preserve os registos e os mapeamentos atuais dos volumes antes de qualquer alteração. Recorra à restauração apenas depois de confirmar que o estado original está indisponível, em vez de estar simplesmente desligado.