O status do Zimbra zmcontrol mostra que os serviços do host foram interrompidos: um guia de solução de problemas.

Exemplo hipotético: Alex, o administrador do servidor Zimbra de uma pequena empresa, recebe relatórios de que o webmail está indisponível após uma janela de manutenção de rotina do host. No servidor, Alex executa o comando zmcontrol statuse vê mailbox Stopped, enquanto o LDAP e o MTA mostram Running. Este é um cenário ilustrativo, não um relato de uma interrupção real ou um teste. O primeiro passo importante é encontrar o erro de inicialização do componente com falha antes de reiniciar toda a infraestrutura ou excluir arquivos.

zmcontrol statusRelata o estado do serviço reconhecido pelo host Zimbra instalado. Um serviço parado é um sintoma, não um diagnóstico: a causa pode ser um sistema de arquivos cheio, uma dependência com falha, um conflito de porta, uma falha de processo ou um problema específico da versão. Os nomes e funções dos serviços variam entre as versões do Zimbra e as implantações em servidor único ou em vários servidores. As referências de comandos disponíveis no Centro de Tecnologia do Zimbra incluem material antigo e arquivado; portanto, use-as para orientação básica e verifique qualquer operação corretiva com a documentação ou o suporte da sua versão instalada. Este guia foi verificado com base nas referências oficiais do Zimbra em 6 de outubro de 2026.

1. Registre o que foi interrompido antes de alterar qualquer coisa.

Faça login no host Zimbra afetado, torne-se o usuário do sistema operacional Zimbra e registre a versão do produto e a saída de status completa:

su - zimbra
zmcontrol -v
zmcontrol status

Salve o resultado e anote o horário da verificação. No caso hipotético de Alex, o detalhe crucial é que a caixa de correio está parada, mas o LDAP e o MTA são relatados como em execução. Se vários componentes estiverem parados, anote a ordem em que pararam e se uma atualização recente, reinicialização, alteração de certificado, evento de armazenamento ou edição de configuração precedeu o problema. Em uma implantação com vários servidores, execute a verificação de status em cada host afetado; um nó de caixa de correio, um nó LDAP e um nó MTA têm funções e dependências diferentes.

A documentação de comandos do Zimbra descreve zmcontrol statusa exibição dos estados "Em execução" ou "Parado" para os componentes, mas os exemplos listados são de versões mais antigas do ZCS. A saída atual no seu servidor é o inventário relevante. Consulte a documentação do zmcontrol do Zimbra e verifique suas categorias e contexto de versão antes de aplicar procedimentos específicos da versão.

2. Verifique os registros recentes em busca da primeira falha.

Procure por erros ocorridos no mesmo horário em que o serviço foi interrompido. Para uma instalação típica, locais úteis incluem /var/log/zimbra.logos arquivos em `/etc/zimbra` e `/etc/zimbra` /opt/zimbra/log. Os logs exatos presentes dependem da versão do Zimbra e dos serviços habilitados.

sudo tail -n 200 /var/log/zimbra.log
tail -n 200 /opt/zimbra/log/mailbox.log
tail -n 200 /opt/zimbra/log/zmmailboxd.out

Execute os comandos com uma conta que possa ler os arquivos; use-a sudosomente quando necessário. Procure o primeiro erro específico, não apenas mensagens repetidas de "serviço interrompido". Exemplos incluem "Sem espaço disponível no dispositivo", um erro de vinculação ou de endereço em uso, uma falha na conexão LDAP, uma falha na conexão com o banco de dados, um erro de permissão ou o encerramento de um processo Java. Uma sequência posterior de falhas pode simplesmente refletir uma dependência anterior que falhou primeiro.

Para Alex, se mailbox.logo mailboxd mostrar que não conseguiu se conectar ao LDAP, o próximo passo é diagnosticar a conectividade LDAP em vez de reiniciar o mailboxd repetidamente. A página de solução de problemas do Zimbra lista os logs de servidor comuns, incluindo `mail_system` mailbox.log, zimbra.log`mail_system`, nginx.log`mail_system` e zmmailboxd.out`mail_system`, e recomenda coletar os trechos relevantes ao relatar um problema. Consulte as orientações de solução de problemas e coleta de logs do Zimbra .

3. Descartar problemas no nível do host

Antes de tentar iniciar o sistema, verifique os recursos e a identidade básica do host. Essas verificações de leitura podem revelar rapidamente causas comuns relacionadas ao sistema operacional:

df -h /opt/zimbra /var/log
df -i /opt/zimbra /var/log
free -h
uptime
hostname -f
timedatectl status

Se um volume de dados ou de logs do Zimbra estiver cheio, libere espaço através dos procedimentos normais de retenção e capacidade do sistema; não remova arquivos de mensagens, bancos de dados ou logs indiscriminadamente. Um número insuficiente de inodes pode impedir a criação de novos arquivos, mesmo quando o sistema de arquivos aparentemente possui capacidade livre. Pouca memória ou carga excepcionalmente alta também podem impedir que os serviços de caixa de correio baseados em Java sejam iniciados de forma confiável.

Confirme se o nome totalmente qualificado do host é resolvido conforme o esperado para sua implementação. Se um nome de host ou registro DNS foi alterado, compare-o com o nome configurado do servidor e com os outros nós do Zimbra. Verifique também atualizações recentes de pacotes, renovações de certificados, alterações de firewall e montagens de armazenamento. Se o servidor foi reiniciado, verifique se os volumes de dados necessários foram montados antes de iniciar os serviços.

4. Solucione os problemas em ordem de dependência.

Comece pela dependência mais antiga exibida nos logs ou interrompida na saída de status. O LDAP é especialmente importante porque os componentes do Zimbra usam informações de diretório para configuração e autenticação. Se o LDAP estiver inativo, os serviços subsequentes podem falhar, mesmo que seus próprios arquivos e processos pareçam intactos. Verifique as entradas relacionadas ao LDAP em `/etc/ldap/` zimbra.log, confirme a resolução de host e a conectividade entre os nós e verifique se o volume de dados do LDAP está montado e gravável. Não tente recuperar o banco de dados ou reconstruir os dados do diretório com base em uma lista de verificação genérica; essas ações podem causar perda de dados e devem corresponder à versão do produto e ao estado do backup.

Se o LDAP estiver íntegro, mas mailboxparado, inspecione mailbox.logos sockets zmmailboxd.outde escuta. Verifique o espaço em disco, a memória disponível e se outro processo está utilizando a porta ou o endereço necessário para o mailboxd. Um administrador pode inspecionar os sockets de escuta com o comando:

sudo ss -ltnp

Compare a saída com as portas configuradas nesta instalação. Evite interromper um servidor web não relacionado apenas porque uma página antiga de solução de problemas menciona um conflito de portas; primeiro identifique o processo e confirme se é seguro interrompê-lo. A página antiga de solução de problemas de caixa de correio do Zimbra documenta um padrão de falha na inicialização da caixa de correio, mas se classifica como arquivada e sem suporte para versões recentes. Considere-a como um exemplo de sintoma, não como um procedimento de reparo universal: notas arquivadas de solução de problemas de caixa de correio do Zimbra .

Se mtao serviço for interrompido, verifique os erros de transferência de e-mail zimbra.loge confirme se o host do MTA consegue acessar o serviço LDAP configurado. A função do MTA inclui receber e retransmitir e-mails, e as mensagens em fila podem permanecer adiadas enquanto a entrega não estiver disponível. Inspecione a fila somente após confirmar os comandos apropriados para a sua versão; não execute comandos como primeiro passo: liberar, excluir ou reenfileirar mensagens. A visão geral do MTA do Zimbra explica a relação entre o Postfix, o LDAP e as filas de entrada, ativas, adiadas e de espera: Visão geral da arquitetura e das filas do MTA do Zimbra .

5. Tente iniciar o serviço de forma controlada.

Após coletar as evidências e corrigir a causa identificada no nível do host, inicie os serviços usando o comando compatível com a versão instalada e a função do servidor. Em instalações padrão do Zimbra Collaboration, os administradores geralmente executam o comando zmcontrol startcomo o usuário Zimbra.

su - zimbra
zmcontrol start

Observe a saída de cada componente. Se um serviço reportar FAILEDum erro, registre a mensagem exata e pare de repetir a mesma tentativa de inicialização até que você tenha examinado o log correspondente. Um comando de inicialização pode revelar erros úteis, mas reinicializações repetidas podem mascarar a falha original ou interromper componentes que ainda estão atendendo usuários. Evite executar comandos abrangentes, como `start` stop, shutdown`start` ou ` restartstart`, durante um incidente ativo, a menos que você tenha uma janela de manutenção e compreenda o impacto em cada nó.

Não exclua arquivos PID, não encerre processos com `sudo` kill -9, não modifique a configuração do Postfix gerada e não execute comandos de reparo de LDAP/banco de dados apenas porque uma página antiga da wiki os lista. Essas etapas dependem muito do estado do processo e da versão do software. Primeiro, verifique se um processo está realmente órfão, siga o procedimento específico do fornecedor para a versão em questão e certifique-se de que exista um backup atualizado. As páginas públicas de solução de problemas do Zimbra variam em idade e algumas contêm avisos explícitos de arquivo ou de trabalho em andamento.

6. Use a saída de status para restringir a próxima ação.

• LDAP parado, vários serviços parados: investigue o próprio log de inicialização do LDAP, DNS, resolução de nomes de host, volume de dados e conectividade entre nós antes de diagnosticar os serviços subsequentes.
• Caixa de correio interrompida, LDAP em execução: utilize os logs da caixa de correio, verificações de memória e disco do host e inspeção do listener para procurar a primeira falha do mailboxd.
• MTA parado, caixa de correio em execução: verifique os logs do MTA, a acessibilidade LDAP, erros de geração de configuração e se o servidor consegue vincular os listeners SMTP configurados.
• Apenas o registro de logs, estatísticas, antispam ou antivírus está parado: determine se esse componente é necessário para o fluxo de e-mails afetado neste servidor. Seu status pode afetar o monitoramento ou a filtragem sem explicar uma interrupção do webmail.
• Todos os componentes mostram o status "Em execução", mas os usuários ainda não conseguem se conectar: ​​verifique o proxy da web, o balanceador de carga externo, o DNS, o firewall, o certificado TLS e o endpoint relevante voltado para o cliente. Um processo em execução não comprova que os clientes conseguem acessar o serviço.

No exemplo hipotético, Alex não deve concluir que todo o servidor Zimbra está íntegro apenas porque o LDAP e o MTA estão em execução; a caixa de correio continua sendo a causa direta da indisponibilidade do webmail. Se os logs da caixa de correio apontarem para o LDAP, apesar de seu estado de execução, teste a conexão configurada entre esses serviços em vez de confiar apenas no rótulo de resumo.

7. Confirme a recuperação do ponto de vista do usuário.

Após a tentativa de inicialização, execute zmcontrol statusnovamente e confirme se o serviço anteriormente interrompido agora está em execução. Em seguida, verifique o log do serviço em busca de novos erros de inicialização. Um status de sucesso é necessário, mas não suficiente: verifique se os administradores conseguem acessar a interface web, se uma conta de teste autorizada consegue fazer login e se o fluxo de e-mails esperado está funcionando. Para um incidente com o MTA, confirme se as novas mensagens de entrada e saída estão sendo entregues e se a fila está diminuindo em vez de aumentar.

No exemplo de Alex, a recuperação significa que a caixa de correio permanece em execução após a inicialização, os registros da caixa de correio não mostram mais a dependência original ou o erro de vinculação, e um usuário de teste consegue acessar o webmail. Se o status retornar para Parado, preserve a nova saída de inicialização e os trechos de registro correspondentes em vez de repetir o processo de reinicialização. Essas evidências ajudam a distinguir uma falha de dependência persistente de um processo que inicia e, em seguida, trava.

Quando escalar o problema

Contate o Suporte do Zimbra ou o administrador responsável pela implantação se o LDAP não iniciar, se ocorrer um erro de integridade do banco de dados ou diretório, se um serviço falhar repetidamente, se o sistema for um cluster com vários nós e apresentar estado inconsistente ou se a próxima ação proposta envolver a exclusão de dados ou a alteração da configuração gerada. Inclua a versão e a compilação do Zimbra, a versão do sistema operacional, a função e a topologia do servidor, zmcontrol statusa saída exata, o histórico de alterações recentes e trechos de logs referentes ao momento da falha. Oculte senhas, chaves privadas, tokens de autenticação e conteúdo de mensagens pessoais antes de compartilhar os logs.

O objetivo prático é identificar a primeira dependência com falha, fazer uma correção adequada à versão e verificar o comportamento do serviço tanto no nível do processo quanto no nível do usuário. Essa abordagem ajuda a restaurar o serviço de e-mail, reduzindo o risco de transformar a interrupção de um único componente em uma falha mais ampla.