Zimbra zmcontrol Status Shows Host Services Stopped: A Troubleshooting Guide

Hypothetical example: Alex, the administrator of a small company’s Zimbra server, receives reports that webmail is unavailable after a routine host maintenance window. From the server, Alex runs zmcontrol status and sees mailbox Stopped, while LDAP and the MTA show Running. This is an illustrative scenario, not a report of a real outage or test. The important first move is to find the failed component’s startup error before restarting the entire stack or deleting files.

zmcontrol status reports the service state recognized by the installed Zimbra host. A stopped service is a symptom, not a diagnosis: the cause could be a full filesystem, a failed dependency, a port conflict, a process crash, or a version-specific issue. Service names and roles vary across Zimbra versions and single-server or multi-server deployments. The command references available in Zimbra’s Tech Center include older and archived material, so use them for basic orientation and verify any corrective operation against documentation or support for your installed release. This guide was checked against official Zimbra references on October 6, 2026.

1. Record what is stopped before changing anything

Log in to the affected Zimbra host, become the Zimbra operating-system user, and record the product version and full status output:

su - zimbra
zmcontrol -v
zmcontrol status

Save the output and note the time of the check. In Alex’s hypothetical case, the key detail is that mailbox is stopped but LDAP and MTA are reported as running. If several components are stopped, note their order and whether a recent update, reboot, certificate change, storage event, or configuration edit preceded the problem. In a multi-server deployment, run the status check on each affected host; a mailbox node, LDAP node, and MTA node have different roles and dependencies.

The Zimbra command reference describes zmcontrol status as showing Running or Stopped states for components, but its listed examples are from older ZCS releases. The current output on your server is the relevant inventory. See the Zimbra zmcontrol reference and check its categories and version context before applying release-specific procedures.

2. Check recent logs for the first failure

Look for errors from the same time the service stopped. For a typical packaged installation, useful locations include /var/log/zimbra.log and files under /opt/zimbra/log. The exact logs present depend on the Zimbra release and enabled services.

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

Run commands with an account that can read the files; use sudo only where required. Look for the earliest specific error, not just repeated “service stopped” messages. Examples include “No space left on device,” a bind or address-in-use error, a failed LDAP connection, a database connection failure, a permission error, or a Java process exit. A later cascade of failures may simply reflect an earlier dependency failing first.

For Alex, if mailbox.log shows that mailboxd could not connect to LDAP, the next step is to diagnose LDAP connectivity rather than repeatedly restarting mailboxd. Zimbra’s troubleshooting page lists common server logs, including mailbox.log, zimbra.log, nginx.log, and zmmailboxd.out, and recommends collecting the time-relevant excerpts when escalating an issue. See Zimbra’s troubleshooting and log-gathering guidance.

3. Rule out host-level problems

Before attempting a start, check resources and basic host identity. These read-only checks can quickly reveal common operating-system causes:

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

If a Zimbra data or log volume is full, free space through the system’s normal retention and capacity procedures; do not remove message stores, database files, or logs blindly. An exhausted inode count can prevent new files from being created even when a filesystem appears to have free capacity. Low memory or unusually high load can also prevent Java-based mailbox services from starting reliably.

Confirm that the host’s fully qualified name resolves as expected for your deployment. If a hostname or DNS record changed, compare it with the server’s configured name and the other Zimbra nodes. Also check recent package updates, certificate renewals, firewall changes, and storage mounts. If the server was rebooted, verify that required data volumes mounted before starting services.

4. Troubleshoot in dependency order

Start with the earliest dependency shown in the logs or stopped in the status output. LDAP is especially important because Zimbra components use directory information for configuration and authentication. If LDAP is down, downstream services may fail even when their own files and processes appear intact. Check the LDAP-related entries in zimbra.log, confirm host resolution and connectivity between nodes, and verify that the LDAP data volume is mounted and writable. Do not attempt database recovery or rebuild directory data based on a generic checklist; those actions can cause data loss and must match the product version and backup state.

If LDAP is healthy but mailbox is stopped, inspect mailbox.log and zmmailboxd.out. Check disk space, available memory, and whether another process owns the port or address that mailboxd needs. An administrator can inspect listening sockets with:

sudo ss -ltnp

Compare the output with the ports configured on this installation. Avoid stopping an unrelated web server merely because a historical troubleshooting page mentions a port conflict; first identify the process and confirm that it is safe to stop. Zimbra’s older mailbox troubleshooting page documents a mailbox startup failure pattern, but labels itself archived and unsupported for recent versions. Treat it as a symptom example, not a universal repair procedure: archived Zimbra mailbox troubleshooting notes.

If mta is stopped, inspect mail-transfer errors in zimbra.log and confirm that the MTA host can reach its configured LDAP service. The MTA’s role includes receiving and relaying mail, and queued messages may remain deferred while delivery is unavailable. Inspect the queue only after confirming the appropriate commands for your release; do not flush, delete, or requeue messages as a first response. Zimbra’s MTA overview explains the relationship between Postfix, LDAP, and the incoming, active, deferred, and hold queues: Zimbra MTA architecture and queue overview.

5. Try a controlled service start

Once you have captured the evidence and corrected an identified host-level cause, start services using the command supported by your installed release and server role. On standard Zimbra Collaboration installations, administrators commonly run zmcontrol start as the Zimbra user:

su - zimbra
zmcontrol start

Watch the output for each component. If a service reports FAILED, record the exact message and stop repeating the same start attempt until you have examined the corresponding log. A startup command can expose useful errors, but repeated restarts may obscure the original failure or interrupt components that are still serving users. Avoid running broad stop, shutdown, or restart commands during an active incident unless you have a maintenance window and understand the impact on every node.

Do not delete PID files, kill processes with kill -9, modify generated Postfix configuration, or run LDAP/database repair commands just because an old wiki page lists them. Such steps are highly dependent on the process state and software version. First verify that a process is genuinely orphaned, follow the exact release-specific vendor procedure, and ensure a current backup exists. Zimbra’s public troubleshooting pages vary in age and some explicitly carry archive or work-in-progress notices.

6. Use the status output to narrow the next action

• LDAP stopped, several services stopped: investigate LDAP’s own startup log, DNS, hostname resolution, data volume, and inter-node connectivity before diagnosing downstream services.
• Mailbox stopped, LDAP running: use mailbox logs, host memory and disk checks, and listener inspection to look for the first mailboxd failure.
• MTA stopped, mailbox running: check MTA logs, LDAP reachability, configuration-generation errors, and whether the server can bind the configured SMTP listeners.
• Only logger, stats, antispam, or antivirus is stopped: determine whether that component is required for the affected mail flow on this server. Its status may affect monitoring or filtering without explaining a webmail outage.
• All components show Running but users still cannot connect: check the web proxy, external load balancer, DNS, firewall, TLS certificate, and the relevant client-facing endpoint. A Running process does not prove that clients can reach the service.

In the hypothetical example, Alex should not conclude that the entire Zimbra server is healthy just because LDAP and MTA are Running; mailbox remains the direct reason webmail may be unavailable. If the mailbox logs point to LDAP despite its Running state, test the configured connection between those services rather than relying on the summary label alone.

7. Confirm recovery from the user’s point of view

After the start attempt, run zmcontrol status again and confirm that the formerly stopped service reports Running. Then check the service’s own log for fresh startup errors. A successful status is necessary but not sufficient: verify that administrators can reach the web interface, an authorized test account can sign in, and the expected mail flow works. For an MTA incident, confirm that new inbound and outbound messages are delivered and that the queue is draining rather than growing.

For Alex’s example, recovery means mailbox stays Running after startup, the mailbox logs no longer show the original dependency or bind error, and a test user can access webmail. If status returns to Stopped, preserve the new startup output and matching log excerpts instead of looping through restarts. That evidence helps distinguish a persistent dependency failure from a process that starts and then crashes.

When to escalate

Contact Zimbra Support or the administrator responsible for the deployment if LDAP will not start, a database or directory integrity error appears, a service repeatedly crashes, the system is a multi-node cluster with inconsistent state, or the next proposed action involves deleting data or changing generated configuration. Include the Zimbra version and build, operating-system version, server role and topology, exact zmcontrol status output, recent change history, and log excerpts covering the failure time. Redact passwords, private keys, authentication tokens, and personal message content before sharing logs.

The practical goal is to identify the first failed dependency, make one version-appropriate correction, and verify service behavior at both the process and user levels. That approach helps restore mail service while reducing the risk of turning a single stopped component into a wider outage.