Le statut de Zimbra zmcontrol indique que les services hôtes sont arrêtés : guide de dépannage

Exemple hypothétique : Alex, administrateur du serveur Zimbra d'une petite entreprise, reçoit des rapports indiquant que la messagerie web est indisponible après une opération de maintenance de routine. Sur le serveur, Alex exécute la commande zmcontrol statuset constate que la messagerie web est indisponible mailbox Stopped, tandis que LDAP et le MTA affichent une Runningerreur. Il s'agit d'un scénario illustratif, et non d'un rapport de panne réelle ou d'un test. La première étape cruciale consiste à identifier l'erreur de démarrage du composant défaillant avant de redémarrer l'ensemble du système ou de supprimer des fichiers.

zmcontrol statusCe rapport indique l'état du service reconnu par l'hôte Zimbra installé. Un service arrêté est un symptôme, et non un diagnostic : la cause peut être un système de fichiers saturé, une dépendance défaillante, un conflit de ports, un plantage de processus ou un problème spécifique à la version. Les noms et les rôles des services varient selon les versions de Zimbra et les déploiements (mono-serveur ou multi-serveurs). Les références de commandes disponibles dans le Centre technique de Zimbra contiennent des informations anciennes et archivées ; utilisez-les pour une première approche et vérifiez toute opération corrective auprès de la documentation ou du support technique de votre version installée. Ce guide a été vérifié à l'aide des références officielles de Zimbra le 6 octobre 2026.

1. Notez ce qui est arrêté avant de modifier quoi que ce soit.

Connectez-vous à l'hôte Zimbra concerné, devenez l'utilisateur du système d'exploitation Zimbra et notez la version du produit et le résultat complet de l'état :

su - zimbra
zmcontrol -v
zmcontrol status

Enregistrez le résultat et notez l'heure de la vérification. Dans le cas hypothétique d'Alex, l'élément clé est que la boîte aux lettres est arrêtée, tandis que LDAP et MTA sont signalés comme étant en cours d'exécution. Si plusieurs composants sont arrêtés, notez leur ordre d'arrêt et si une mise à jour récente, un redémarrage, une modification de certificat, un événement de stockage ou une modification de configuration a précédé le problème. Dans un déploiement multi-serveurs, exécutez la vérification d'état sur chaque hôte concerné ; un nœud de boîte aux lettres, un nœud LDAP et un nœud MTA ont des rôles et des dépendances différents.

La documentation de la commande Zimbra indique zmcontrol statusque les composants sont affichés en état « En cours d'exécution » ou « Arrêté », mais les exemples fournis proviennent d'anciennes versions de ZCS. L'affichage actuel sur votre serveur constitue l'inventaire pertinent. Consultez la documentation de Zimbra zmcontrol et vérifiez ses catégories et le contexte de version avant d'appliquer les procédures spécifiques à votre version.

2. Consultez les journaux récents pour identifier la première défaillance.

Recherchez les erreurs survenues au moment même où le service s'est arrêté. Pour une installation standard, les emplacements utiles incluent /var/log/zimbra.logles fichiers situés dans le répertoire `/etc/zimbra` /opt/zimbra/log. Les journaux exacts présents dépendent de la version de Zimbra et des services activés.

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

Exécutez les commandes avec un compte disposant des droits de lecture sur les fichiers ; utilisez-les sudouniquement lorsque cela est nécessaire. Recherchez la première erreur spécifique, et non les messages répétés de type « service arrêté ». Il peut s’agir, par exemple, d’une erreur « Espace insuffisant sur le périphérique », d’une erreur de liaison ou d’adresse déjà utilisée, d’une connexion LDAP échouée, d’une erreur de connexion à la base de données, d’une erreur d’autorisation ou de l’arrêt d’un processus Java. Une série d’erreurs ultérieures peut simplement indiquer la défaillance d’une dépendance antérieure.

Pour Alex, si mailbox.logle message indique que mailboxd n'a pas pu se connecter à LDAP, l'étape suivante consiste à diagnostiquer la connectivité LDAP plutôt que de redémarrer mailboxd à répétition. La page de dépannage de Zimbra répertorie les journaux serveur courants, notamment `<chemin_vers_les_journaux_serveurs_src>`, `<chemin_vers_les_journaux_serveurs_src>`, `<chemin_vers_les_journaux_serveurs_src>` et mailbox.log` <chemin_vers_les_journaux_serveurs_src> `, et recommande de collecter les extraits pertinents lors de l'escalade d'un problème. Consultez le guide de dépannage et de collecte des journaux de Zimbra .zimbra.lognginx.logzmmailboxd.out

3. Éliminer les problèmes au niveau de l'hôte

Avant de tenter un démarrage, vérifiez les ressources et l'identité de l'hôte. Ces vérifications en lecture seule permettent de déceler rapidement les causes courantes liées au système d'exploitation :

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

Si un volume de données ou de journalisation Zimbra est plein, libérez de l'espace via les procédures de rétention et de gestion de capacité habituelles du système ; ne supprimez pas les fichiers de messagerie, de base de données ou les journaux sans précaution. Un nombre d'inodes épuisé peut empêcher la création de nouveaux fichiers, même si le système de fichiers semble disposer d'espace libre. Une mémoire insuffisante ou une charge anormalement élevée peuvent également empêcher le bon démarrage des services de messagerie Java.

Vérifiez que le nom de domaine complet de l'hôte est correctement résolu pour votre déploiement. Si un nom d'hôte ou un enregistrement DNS a été modifié, comparez-le avec le nom configuré du serveur et celui des autres nœuds Zimbra. Vérifiez également les mises à jour récentes des paquets, les renouvellements de certificats, les modifications du pare-feu et les montages de stockage. Si le serveur a été redémarré, assurez-vous que les volumes de données requis sont montés avant de démarrer les services.

4. Dépanner en respectant l'ordre de dépendance

Commencez par la dépendance la plus ancienne indiquée dans les journaux ou arrêtée dans la sortie d'état. LDAP est particulièrement important car les composants Zimbra utilisent les informations d'annuaire pour la configuration et l'authentification. Si LDAP est indisponible, les services en aval peuvent tomber en panne même si leurs propres fichiers et processus semblent intacts. Vérifiez les entrées liées à LDAP zimbra.log, confirmez la résolution des hôtes et la connectivité entre les nœuds, et assurez-vous que le volume de données LDAP est monté et accessible en écriture. N'essayez pas de récupérer la base de données ni de reconstruire les données d'annuaire à partir d'une liste de contrôle générique ; ces actions peuvent entraîner une perte de données et doivent correspondre à la version du produit et à l'état de la sauvegarde.

Si LDAP est opérationnel mais mailboxarrêté, inspectez mailbox.log-le zmmailboxd.out. Vérifiez l'espace disque, la mémoire disponible et si un autre processus utilise le port ou l'adresse requis par mailboxd. Un administrateur peut inspecter les sockets d'écoute avec :

sudo ss -ltnp

Comparez la sortie avec les ports configurés sur cette installation. Évitez d'arrêter un serveur web non lié à la problématique simplement parce qu'une ancienne page de dépannage mentionne un conflit de ports ; identifiez d'abord le processus et assurez-vous qu'il peut être arrêté sans risque. L'ancienne page de dépannage de la messagerie Zimbra décrit un schéma d'échec au démarrage de la messagerie, mais elle est archivée et n'est plus prise en charge pour les versions récentes. Considérez-la comme un exemple de symptôme, et non comme une procédure de réparation universelle : notes de dépannage archivées de la messagerie Zimbra .

En cas mtad'arrêt du service, examinez les erreurs de transfert de courrier zimbra.loget vérifiez que l'hôte MTA peut accéder à son service LDAP configuré. Le rôle du MTA inclut la réception et le relais du courrier ; les messages en file d'attente peuvent rester différés tant que la distribution est indisponible. N'examinez la file d'attente qu'après avoir validé les commandes appropriées pour votre version ; ne videz pas, ne supprimez pas et ne remettez pas les messages en file d'attente dans un premier temps. La présentation du MTA de Zimbra explique la relation entre Postfix, LDAP et les files d'attente entrantes, actives, différées et en attente : Architecture et présentation des files d'attente du MTA de Zimbra .

5. Essayez un démarrage de service contrôlé

Une fois les preuves recueillies et la cause identifiée au niveau de l'hôte corrigée, démarrez les services à l'aide de la commande prise en charge par votre version et votre rôle serveur. Sur les installations standard de Zimbra Collaboration, les administrateurs exécutent généralement cette commande zmcontrol starten tant qu'utilisateur Zimbra.

su - zimbra
zmcontrol start

Surveillez la sortie de chaque composant. Si un service signale une erreur FAILED, notez le message exact et cessez de répéter la même tentative de démarrage tant que vous n'avez pas examiné le journal correspondant. Une commande de démarrage peut révéler des erreurs utiles, mais des redémarrages répétés peuvent masquer la panne initiale ou interrompre des composants qui continuent de fournir des services aux utilisateurs. Évitez d'exécuter des commandes générales pendant un incident actif stop, sauf si vous disposez d'une fenêtre de maintenance et que vous comprenez l'impact sur chaque nœud.shutdownrestart

Ne supprimez pas les fichiers PID, n'interrompez pas les processus kill -9, ne modifiez pas la configuration Postfix générée et n'exécutez pas de commandes de réparation LDAP/base de données simplement parce qu'une ancienne page wiki le mentionne. Ces actions dépendent fortement de l'état du processus et de la version du logiciel. Vérifiez d'abord qu'un processus est réellement orphelin, suivez la procédure spécifique à la version et assurez-vous de disposer d'une sauvegarde récente. Les pages de dépannage publiques de Zimbra sont d'ancienneté variable et certaines comportent des mentions d'archivage ou de travail en cours.

6. Utilisez le résultat de l'état pour cibler la prochaine action.

• LDAP arrêté, plusieurs services arrêtés : examinez le journal de démarrage de LDAP, le DNS, la résolution de noms d’hôtes, le volume de données et la connectivité entre les nœuds avant de diagnostiquer les services en aval.
• Boîte aux lettres arrêtée, LDAP en cours d'exécution : utilisez les journaux de boîte aux lettres, les vérifications de la mémoire et du disque de l'hôte, ainsi que l'inspection du listener pour rechercher la première défaillance de mailboxd.
• MTA arrêté, boîte aux lettres en cours d'exécution : vérifiez les journaux MTA, l'accessibilité LDAP, les erreurs de génération de configuration et si le serveur peut lier les écouteurs SMTP configurés.
• Seuls les services de journalisation, de statistiques, d'antispam ou d'antivirus sont arrêtés : déterminez si ce composant est indispensable au bon fonctionnement du flux de messagerie sur ce serveur. Son état peut affecter la surveillance ou le filtrage sans pour autant expliquer une interruption du service de messagerie web.
• Tous les composants sont indiqués comme étant en cours d'exécution, mais les utilisateurs ne peuvent toujours pas se connecter : vérifiez le proxy web, l'équilibreur de charge externe, le DNS, le pare-feu, le certificat TLS et le point de terminaison client concerné. Un processus en cours d'exécution ne garantit pas que les clients peuvent accéder au service.

Dans cet exemple hypothétique, Alex ne doit pas conclure que le serveur Zimbra est entièrement opérationnel simplement parce que LDAP et MTA sont en cours d'exécution ; la boîte aux lettres reste la cause directe de l'indisponibilité du webmail. Si les journaux de la boîte aux lettres pointent vers LDAP malgré son état « En cours d'exécution », il convient de tester la connexion configurée entre ces services plutôt que de se fier uniquement à l'étiquette récapitulative.

7. Confirmer la récupération du point de vue de l'utilisateur

Après la tentative de démarrage, relancez le zmcontrol statusservice et vérifiez qu'il est bien en cours d'exécution. Consultez ensuite le journal du service pour détecter d'éventuelles erreurs de démarrage. Un démarrage réussi est nécessaire, mais non suffisant : assurez-vous que les administrateurs peuvent accéder à l'interface web, qu'un compte de test autorisé peut s'y connecter et que le flux de messagerie fonctionne correctement. En cas d'incident lié au MTA, vérifiez que les nouveaux messages entrants et sortants sont bien distribués et que la file d'attente se vide au lieu de s'allonger.

Dans l'exemple d'Alex, la récupération signifie que la boîte aux lettres reste en cours d'exécution après le démarrage, que les journaux de la boîte aux lettres ne présentent plus l'erreur de dépendance ou de liaison initiale, et qu'un utilisateur de test peut accéder à la messagerie web. Si l'état repasse à « Arrêté », conservez la nouvelle sortie de démarrage et les extraits de journal correspondants au lieu de parcourir les redémarrages en boucle. Ces éléments permettent de distinguer une défaillance de dépendance persistante d'un processus qui démarre puis plante.

Quand faut-il intensifier les efforts ?

Contactez le support Zimbra ou l'administrateur responsable du déploiement si LDAP ne démarre pas, si une erreur d'intégrité de base de données ou d'annuaire survient, si un service plante de manière répétée, si le système est un cluster multi-nœuds avec un état incohérent, ou si la prochaine action proposée implique la suppression de données ou la modification de la configuration générée. Indiquez la version et la build de Zimbra, la version du système d'exploitation, le rôle et la topologie du serveur, zmcontrol statusla sortie exacte, l'historique des modifications récentes et des extraits de journaux couvrant l'heure de la panne. Masquez les mots de passe, les clés privées, les jetons d'authentification et le contenu des messages personnels avant de partager les journaux.

L'objectif pratique est d'identifier la première dépendance défaillante, d'effectuer une correction adaptée à la version et de vérifier le comportement du service au niveau des processus et des utilisateurs. Cette approche permet de rétablir le service de messagerie tout en limitant le risque qu'une panne isolée entraîne une interruption plus importante.