El estado de Zimbra zmcontrol muestra que los servicios del host se han detenido: Guía de solución de problemas

Ejemplo hipotético: Alex, administrador del servidor Zimbra de una pequeña empresa, recibe informes de que el correo web no está disponible tras una ventana de mantenimiento rutinaria. Desde el servidor, Alex ejecuta zmcontrol statusy ve mailbox Stopped, mientras que LDAP y el MTA muestran Running. Este es un escenario ilustrativo, no un informe de una interrupción real ni una prueba. El primer paso importante es encontrar el error de inicio del componente que falla antes de reiniciar todo el sistema o eliminar archivos.

zmcontrol statusEste informe muestra el estado del servicio reconocido por el host Zimbra instalado. Un servicio detenido es un síntoma, no un diagnóstico: la causa podría ser un sistema de archivos lleno, una dependencia fallida, un conflicto de puertos, un fallo del proceso o un problema específico de la versión. Los nombres y roles de los servicios varían según las versiones de Zimbra y las implementaciones de un solo servidor o de varios servidores. Las referencias de comandos disponibles en el Centro Tecnológico de Zimbra incluyen material antiguo y archivado, por lo que le recomendamos usarlas como guía básica y verificar cualquier operación correctiva con la documentación o el soporte para su versión instalada. Esta guía se revisó con las referencias oficiales de Zimbra el 6 de octubre de 2026.

1. Anota lo que se detiene antes de cambiar nada.

Inicie sesión en el host Zimbra afectado, conviértase en el usuario del sistema operativo Zimbra y registre la versión del producto y la salida de estado completa:

su - zimbra
zmcontrol -v
zmcontrol status

Guarde el resultado y anote la hora de la comprobación. En el caso hipotético de Alex, el detalle clave es que el buzón está detenido, pero LDAP y MTA aparecen como en ejecución. Si varios componentes están detenidos, anote su orden y si una actualización reciente, un reinicio, un cambio de certificado, un evento de almacenamiento o una modificación de la configuración precedieron al problema. En una implementación con varios servidores, ejecute la comprobación de estado en cada host afectado; un nodo de buzón, un nodo LDAP y un nodo MTA tienen diferentes funciones y dependencias.

La documentación de Zimbra sobre comandos zmcontrol statusmuestra los estados de ejecución o detención de los componentes, pero los ejemplos que incluye corresponden a versiones anteriores de ZCS. El inventario relevante se muestra en el servidor. Consulte la documentación de Zimbra zmcontrol y verifique sus categorías y el contexto de la versión antes de aplicar los procedimientos específicos de la versión.

2. Compruebe los registros recientes para detectar el primer fallo.

Busque errores del mismo momento en que se detuvo el servicio. Para una instalación empaquetada típica, las ubicaciones útiles incluyen /var/log/zimbra.logarchivos en /opt/zimbra/log. Los registros exactos presentes dependen de la versión de Zimbra y los servicios 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

Ejecute los comandos con una cuenta que tenga permisos de lectura para los archivos; úsela sudosolo cuando sea necesario. Busque el primer error específico, no solo mensajes repetidos de "servicio detenido". Algunos ejemplos son "No queda espacio en el dispositivo", un error de enlace o de dirección en uso, una conexión LDAP fallida, un fallo en la conexión a la base de datos, un error de permisos o la finalización de un proceso Java. Una cascada de fallos posterior podría simplemente reflejar un fallo previo en una dependencia.

Para Alex, si mailbox.logmuestra que mailboxd no pudo conectarse a LDAP, el siguiente paso es diagnosticar la conectividad LDAP en lugar de reiniciar repetidamente mailboxd. La página de solución de problemas de Zimbra enumera los registros comunes del servidor, incluidos mailbox.log, zimbra.log, nginx.log, y zmmailboxd.out, y recomienda recopilar los extractos relevantes en el tiempo cuando se escala un problema. Consulte la guía de solución de problemas y recopilación de registros de Zimbra .

3. Descartar problemas a nivel del host.

Antes de intentar iniciar el sistema, compruebe los recursos y la identidad básica del host. Estas comprobaciones de solo lectura pueden revelar rápidamente las causas comunes de problemas del sistema operativo:

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

Si un volumen de datos o de registro de Zimbra está lleno, libere espacio mediante los procedimientos normales de retención y gestión de capacidad del sistema; no elimine almacenes de mensajes, archivos de base de datos ni registros indiscriminadamente. Un número de inodos agotado puede impedir la creación de nuevos archivos, incluso cuando el sistema de archivos parece tener capacidad libre. La poca memoria o una carga inusualmente alta también pueden impedir que los servicios de buzón basados ​​en Java se inicien correctamente.

Confirme que el nombre de dominio completo del host se resuelve correctamente para su implementación. Si se modificó un nombre de host o un registro DNS, compárelo con el nombre configurado del servidor y los demás nodos de Zimbra. Verifique también las actualizaciones recientes de paquetes, las renovaciones de certificados, los cambios en el firewall y los puntos de montaje del almacenamiento. Si el servidor se reinició, compruebe que los volúmenes de datos necesarios se montaron antes de iniciar los servicios.

4. Solucionar problemas en orden de dependencia

Comience con la dependencia más antigua que se muestra en los registros o que se detuvo en la salida de estado. LDAP es especialmente importante porque los componentes de Zimbra utilizan información de directorio para la configuración y la autenticación. Si LDAP no está disponible, los servicios dependientes pueden fallar incluso cuando sus propios archivos y procesos parecen intactos. Revise las entradas relacionadas con LDAP en zimbra.log, confirme la resolución de host y la conectividad entre nodos, y verifique que el volumen de datos LDAP esté montado y sea escribible. No intente recuperar la base de datos ni reconstruir los datos del directorio basándose en una lista de verificación genérica; estas acciones pueden causar pérdida de datos y deben coincidir con la versión del producto y el estado de la copia de seguridad.

Si LDAP funciona correctamente pero mailboxestá detenido, inspeccione mailbox.logy zmmailboxd.out. Compruebe el espacio en disco, la memoria disponible y si otro proceso está utilizando el puerto o la dirección que necesita mailboxd. Un administrador puede inspeccionar los sockets en escucha con:

sudo ss -ltnp

Compare la salida con los puertos configurados en esta instalación. Evite detener un servidor web no relacionado solo porque una página de solución de problemas antigua mencione un conflicto de puertos; primero identifique el proceso y confirme que es seguro detenerlo. La página antigua de solución de problemas de buzones de Zimbra documenta un patrón de fallo al iniciar un buzón, pero se etiqueta como archivada y sin soporte para versiones recientes. Trátela como un ejemplo de síntoma, no como un procedimiento de reparación universal: notas archivadas de solución de problemas de buzones de Zimbra .

Si mtase detiene, inspeccione los errores de transferencia de correo zimbra.logy confirme que el host MTA puede acceder a su servicio LDAP configurado. La función del MTA incluye recibir y reenviar correo, y los mensajes en cola pueden permanecer diferidos mientras la entrega no esté disponible. Inspeccione la cola solo después de confirmar los comandos apropiados para su versión; no vacíe, elimine ni vuelva a poner en cola los mensajes como primera respuesta. La descripción general del MTA de Zimbra explica la relación entre Postfix, LDAP y las colas entrantes, activas, diferidas y en espera: Descripción general de la arquitectura y la cola del MTA de Zimbra .

5. Intente un inicio de servicio controlado.

Una vez que haya recopilado la evidencia y corregido la causa identificada a nivel de host, inicie los servicios utilizando el comando compatible con su versión instalada y rol de servidor. En las instalaciones estándar de Zimbra Collaboration, los administradores suelen ejecutar zmcontrol startcomo el usuario Zimbra:

su - zimbra
zmcontrol start

Observe la salida de cada componente. Si un servicio informa de FAILEDun error, registre el mensaje exacto y deje de intentar iniciarlo repetidamente hasta que haya examinado el registro correspondiente. Un comando de inicio puede revelar errores útiles, pero los reinicios repetidos pueden ocultar el fallo original o interrumpir componentes que aún prestan servicio a los usuarios. Evite ejecutar comandos generales durante un incidente activo, stopa menos que disponga de una ventana de mantenimiento y comprenda el impacto en cada nodo.shutdownrestart

No elimine archivos PID, no finalice procesos kill -9, no modifique la configuración de Postfix generada ni ejecute comandos de reparación de LDAP/base de datos solo porque una página wiki antigua los mencione. Estos pasos dependen en gran medida del estado del proceso y de la versión del software. Primero, verifique que un proceso sea realmente huérfano, siga el procedimiento exacto del proveedor específico para su versión y asegúrese de que exista una copia de seguridad actualizada. Las páginas públicas de solución de problemas de Zimbra varían en antigüedad y algunas incluyen avisos explícitos de archivo o de trabajo en curso.

6. Utilice la salida de estado para acotar la siguiente acción.

• LDAP se detuvo, varios servicios se detuvieron: investigue el registro de inicio de LDAP, el DNS, la resolución de nombres de host, el volumen de datos y la conectividad entre nodos antes de diagnosticar los servicios posteriores.
• El buzón de correo se ha detenido, pero LDAP está en funcionamiento: utilice los registros del buzón, las comprobaciones de memoria y disco del host, y la inspección del servicio de escucha para detectar el primer fallo de mailboxd.
• El MTA se ha detenido, pero el buzón de correo está en funcionamiento: compruebe los registros del MTA, la accesibilidad a LDAP, los errores de generación de configuración y si el servidor puede vincularse a los oyentes SMTP configurados.
• Solo se detiene el registro de actividad, las estadísticas, el antispam o el antivirus: determine si dicho componente es necesario para el flujo de correo afectado en este servidor. Su estado puede afectar la monitorización o el filtrado sin explicar la interrupción del servicio de correo web.
• Todos los componentes aparecen como en ejecución, pero los usuarios aún no pueden conectarse: verifique el proxy web, el balanceador de carga externo, el DNS, el firewall, el certificado TLS y el punto final de acceso al cliente correspondiente. Que un proceso esté en ejecución no garantiza que los clientes puedan acceder al servicio.

En el ejemplo hipotético, Alex no debería concluir que todo el servidor Zimbra funciona correctamente solo porque LDAP y MTA estén en ejecución; el buzón de correo sigue siendo la causa directa de que el correo web no esté disponible. Si los registros del buzón de correo apuntan a LDAP a pesar de su estado de ejecución, compruebe la conexión configurada entre esos servicios en lugar de basarse únicamente en la etiqueta de resumen.

7. Confirmar la recuperación desde el punto de vista del usuario.

Tras el intento de inicio, vuelva a ejecutar el servicio zmcontrol statusy confirme que el servicio, que antes estaba detenido, se encuentra en ejecución. A continuación, revise el registro del servicio para detectar nuevos errores de inicio. Un estado correcto es necesario, pero no suficiente: verifique que los administradores puedan acceder a la interfaz web, que una cuenta de prueba autorizada pueda iniciar sesión y que el flujo de correo previsto funcione correctamente. En caso de un incidente de MTA, confirme que se entreguen los mensajes entrantes y salientes nuevos y que la cola se esté vaciando en lugar de aumentar.

En el ejemplo de Alex, la recuperación implica que el buzón permanezca en estado "En ejecución" tras el inicio, que los registros del buzón ya no muestren la dependencia original ni el error de enlace, y que un usuario de prueba pueda acceder al correo web. Si el estado vuelve a "Detenido", se conserva la nueva salida de inicio y los extractos de registro correspondientes en lugar de reiniciar el sistema repetidamente. Esta evidencia ayuda a distinguir un fallo de dependencia persistente de un proceso que se inicia y luego falla.

Cuándo intensificar la escalada

Si LDAP no se inicia, aparece un error de integridad de la base de datos o del directorio, un servicio falla repetidamente, el sistema es un clúster de varios nodos con un estado inconsistente o la siguiente acción propuesta implica eliminar datos o modificar la configuración generada, comuníquese con el soporte de Zimbra o con el administrador responsable de la implementación. Incluya la versión y compilación de Zimbra, la versión del sistema operativo, la función y topología del servidor, zmcontrol statusla salida exacta, el historial de cambios recientes y extractos de los registros que cubran el momento del fallo. Oculte las contraseñas, las claves privadas, los tokens de autenticación y el contenido de los mensajes personales antes de compartir los registros.

El objetivo práctico es identificar la primera dependencia que falla, realizar una corrección adecuada a la versión y verificar el comportamiento del servicio tanto a nivel de proceso como de usuario. Este enfoque ayuda a restablecer el servicio de correo electrónico y reduce el riesgo de que un solo componente detenido provoque una interrupción generalizada.