В сообщении Zimbra zmcontrol Status отображается сообщение "Host Services Stopped": руководство по устранению неполадок.

Гипотетический пример: Алекс, администратор сервера Zimbra в небольшой компании, получает сообщения о недоступности веб-почты после планового технического обслуживания хоста. С сервера Алекс запускает команду zmcontrol statusи видит сообщение об ошибке mailbox Stopped, в то время как LDAP и MTA показывают сообщение Runningоб ошибке. Это иллюстративный сценарий, а не отчет о реальном сбое или тестировании. Важный первый шаг — найти ошибку запуска неисправного компонента, прежде чем перезапускать всю систему или удалять файлы.

zmcontrol statusСообщает о состоянии службы, распознанном установленным хостом Zimbra. Остановленная служба — это симптом, а не диагноз: причиной может быть переполнение файловой системы, сбой зависимости, конфликт портов, сбой процесса или проблема, специфичная для версии. Имена и роли служб различаются в зависимости от версии Zimbra и развертывания на одном или нескольких серверах. Справочники по командам, доступные в Техническом центре Zimbra, содержат более старые и архивные материалы, поэтому используйте их для базовой ориентации и проверяйте любые корректирующие действия по документации или поддержке для вашей установленной версии. Данное руководство было проверено по официальным справочникам Zimbra 6 октября 2026 года.

1. Зафиксируйте, что именно было остановлено, прежде чем что-либо менять.

Войдите на затронутый хост Zimbra, станьте пользователем операционной системы Zimbra и запишите версию продукта и полный вывод состояния:

su - zimbra
zmcontrol -v
zmcontrol status

Сохраните вывод и запишите время проверки. В гипотетическом случае Алекса ключевой деталью является то, что почтовый ящик остановлен, но LDAP и MTA отображаются как работающие. Если остановлено несколько компонентов, запишите их порядок и укажите, предшествовала ли проблема недавним обновлением, перезагрузкой, изменением сертификата, событием, связанным с хранилищем, или редактированием конфигурации. В многосерверной конфигурации выполните проверку состояния на каждом затронутом хосте; узел почтового ящика, узел LDAP и узел MTA имеют разные роли и зависимости.

В справочнике команд Zimbra описывается zmcontrol statusотображение состояний «Работает» или «Остановлено» для компонентов, но приведенные примеры относятся к более старым версиям ZCS. Текущий вывод на вашем сервере — это соответствующий инвентарный список. Перед применением процедур, специфичных для вашей версии, ознакомьтесь со справочником Zimbra zmcontrol и проверьте его категории и контекст версии.

2. Проверьте последние журналы на наличие первого сбоя.

Найдите ошибки, относящиеся к тому же моменту, когда служба была остановлена. Для типичной установки из пакета полезные места расположения /var/log/zimbra.logфайлов включают в себя и /opt/zimbra/log. Точный набор присутствующих журналов зависит от версии Zimbra и включенных служб.

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

Выполняйте команды от имени учетной записи, имеющей право читать файлы; используйте их sudoтолько там, где это необходимо. Ищите самую раннюю конкретную ошибку, а не просто повторяющиеся сообщения «служба остановлена». Примеры включают «Нет места на устройстве», ошибку привязки или использования адреса, сбой подключения к LDAP, сбой подключения к базе данных, ошибку прав доступа или завершение процесса Java. Последующая каскадная ошибка может просто отражать сбой более ранней зависимости.

В случае с Алексом, если mailbox.logотображается сообщение о том, что mailboxd не смог подключиться к LDAP, следующим шагом является диагностика проблем с подключением к LDAP, а не многократный перезапуск mailboxd. На странице устранения неполадок Zimbra перечислены распространенные журналы сервера, включая mailbox.log, zimbra.log, nginx.log, и zmmailboxd.out, и рекомендуется собирать соответствующие по времени фрагменты при передаче проблемы на более высокий уровень. См. руководство Zimbra по устранению неполадок и сбору журналов .

3. Исключите проблемы на уровне хоста.

Перед началом работы проверьте ресурсы и основные параметры идентификации хоста. Эти проверки, доступные только для чтения, могут быстро выявить распространенные причины проблем с операционной системой:

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

Если том данных или журналов Zimbra заполнен, освободите место с помощью стандартных процедур хранения и управления емкостью системы; не удаляйте хранилища сообщений, файлы баз данных или журналы вслепую. Исчерпание количества inode может препятствовать созданию новых файлов, даже если файловая система, кажется, имеет свободную емкость. Недостаток памяти или необычно высокая нагрузка также могут препятствовать надежному запуску почтовых служб на основе Java.

Убедитесь, что полное имя хоста разрешается должным образом для вашей системы. Если имя хоста или запись DNS изменились, сравните их с настроенным именем сервера и другими узлами Zimbra. Также проверьте недавние обновления пакетов, продление сертификатов, изменения в настройках брандмауэра и монтирование хранилищ. Если сервер был перезагружен, убедитесь, что необходимые тома данных смонтированы перед запуском служб.

4. Устранение неполадок в порядке зависимостей.

Начните с самой ранней зависимости, указанной в логах или остановленной в выводе состояния. LDAP особенно важен, поскольку компоненты Zimbra используют информацию из каталогов для конфигурации и аутентификации. Если LDAP недоступен, нижестоящие службы могут выйти из строя, даже если их собственные файлы и процессы кажутся неповрежденными. Проверьте записи, связанные с LDAP zimbra.log, подтвердите разрешение хостов и связь между узлами, а также убедитесь, что том данных LDAP смонтирован и доступен для записи. Не пытайтесь восстанавливать базу данных или перестраивать данные каталога на основе общего контрольного списка; эти действия могут привести к потере данных и должны соответствовать версии продукта и состоянию резервного копирования.

Если LDAP работает исправно, но mailboxостановлен, проверьте mailbox.logи zmmailboxd.out. Проверьте дисковое пространство, доступную память и то, не принадлежит ли порт или адрес, необходимый mailboxd, другому процессу. Администратор может проверить прослушивающие сокеты с помощью:

sudo ss -ltnp

Сравните полученные данные с портами, настроенными в данной установке. Избегайте остановки не связанного с вашей системой веб-сервера только потому, что на старой странице устранения неполадок упоминается конфликт портов; сначала определите процесс и убедитесь, что его безопасно остановить. На старой странице устранения неполадок почтовых ящиков Zimbra описана схема сбоя при запуске почтового ящика, но она помечена как архивная и неподдерживаемая для последних версий. Рассматривайте её как пример симптома, а не как универсальную процедуру устранения неполадок: архивные заметки по устранению неполадок почтовых ящиков Zimbra .

Если mtaпроцесс остановлен, проверьте ошибки передачи почты zimbra.logи убедитесь, что хост MTA может связаться со своей настроенной службой LDAP. Роль MTA включает в себя прием и пересылку почты, и сообщения в очереди могут оставаться в режиме ожидания, пока доставка недоступна. Проверяйте очередь только после подтверждения соответствующих команд для вашей версии; не сбрасывайте, не удаляйте и не ставьте сообщения в очередь в качестве первого ответа. В обзоре MTA Zimbra объясняется взаимосвязь между Postfix, LDAP и очередями входящих, активных, отложенных и удержанных сообщений: Архитектура MTA Zimbra и обзор очередей .

5. Попробуйте контролируемый запуск сервисной службы.

После того как вы соберете доказательства и устраните выявленную причину на уровне хоста, запустите службы, используя команду, поддерживаемую вашей установленной версией и ролью сервера. В стандартных установках Zimbra Collaboration администраторы обычно работают zmcontrol startот имени пользователя Zimbra:

su - zimbra
zmcontrol start

Следите за выводом каждого компонента. Если служба сообщает об ошибке FAILED, запишите точное сообщение и прекратите повторять попытку запуска, пока не изучите соответствующий журнал. Команда запуска может выявить полезные ошибки, но повторные перезапуски могут скрыть первоначальную ошибку или прервать работу компонентов, которые все еще обслуживают пользователей. Избегайте выполнения широких команд, таких как `startup` stop, `startup` shutdownили `startup` restart, во время активного инцидента, если у вас нет окна технического обслуживания и вы не понимаете влияние на каждый узел.

Не удаляйте PID-файлы, не завершайте процессы с помощью команды `call` kill -9, не изменяйте сгенерированную конфигурацию Postfix и не запускайте команды восстановления LDAP/базы данных только потому, что они указаны на старой вики-странице. Такие действия в значительной степени зависят от состояния процесса и версии программного обеспечения. Сначала убедитесь, что процесс действительно является "осиротевшим", следуйте точной процедуре поставщика, специфичной для данной версии, и убедитесь, что существует актуальная резервная копия. Публичные страницы Zimbra по устранению неполадок различаются по времени, и некоторые из них содержат явные уведомления об архиве или незавершенной работе.

6. Используйте информацию о состоянии, чтобы сузить круг дальнейших действий.

• Работа LDAP остановлена, несколько служб остановлены: перед диагностикой нижестоящих служб изучите собственный журнал запуска LDAP, DNS, разрешение имен хостов, объем данных и межсетевое соединение.
• Почтовый ящик остановлен, LDAP запущен: используйте журналы почтового ящика, проверки памяти и диска хоста, а также проверку прослушивателя, чтобы найти первую ошибку mailboxd.
• MTA остановлен, почтовый ящик работает: проверьте журналы MTA, доступность LDAP, ошибки генерации конфигурации и возможность привязки сервером настроенных SMTP-слушателей.
• Остановлены только регистратор, статистика, антиспам или антивирус: определите, необходим ли этот компонент для обработки затронутого потока почты на этом сервере. Его состояние может влиять на мониторинг или фильтрацию, не объясняя причину сбоя веб-почты.
• Все компоненты отображаются как работающие, но пользователи по-прежнему не могут подключиться: проверьте веб-прокси, внешний балансировщик нагрузки, DNS, брандмауэр, TLS-сертификат и соответствующую конечную точку, обращенную к клиенту. Статус «Работает» не доказывает, что клиенты могут получить доступ к сервису.

В гипотетическом примере Алексу не следует делать вывод о работоспособности всего сервера Zimbra только потому, что LDAP и MTA запущены; почтовый ящик остается непосредственной причиной недоступности веб-почты. Если журналы почтового ящика указывают на LDAP, несмотря на его состояние «Запущен», следует проверить настроенное соединение между этими службами, а не полагаться только на сводную метку.

7. Подтвердите восстановление с точки зрения пользователя.

После попытки запуска запустите службу zmcontrol statusеще раз и убедитесь, что ранее остановленная служба отображается как работающая. Затем проверьте собственный журнал службы на наличие новых ошибок запуска. Успешный статус необходим, но недостаточен: убедитесь, что администраторы могут получить доступ к веб-интерфейсу, авторизованная тестовая учетная запись может войти в систему, и что ожидаемый поток почты работает. В случае инцидента с MTA подтвердите, что новые входящие и исходящие сообщения доставляются и что очередь заполняется, а не увеличивается.

В примере Алекса восстановление означает, что почтовый ящик остается в состоянии «Работает» после запуска, в журналах почтового ящика больше не отображается исходная ошибка зависимости или привязки, и тестовый пользователь может получить доступ к веб-почте. Если статус возвращается к «Остановлено», сохраните новый вывод при запуске и соответствующие фрагменты журналов вместо того, чтобы зацикливаться на перезапусках. Эти данные помогают отличить постоянную ошибку зависимости от процесса, который запускается, а затем завершается с ошибкой.

Когда следует перейти к эскалации

В случае, если LDAP не запускается, возникает ошибка целостности базы данных или каталога, служба неоднократно аварийно завершает работу, система представляет собой многоузловой кластер с несогласованным состоянием или если следующие действия предполагают удаление данных или изменение сгенерированной конфигурации, обратитесь в службу поддержки Zimbra или к администратору, ответственному за развертывание. Укажите версию и сборку Zimbra, версию операционной системы, роль и топологию сервера, точный zmcontrol statusвывод, историю последних изменений и выдержки из журналов, охватывающие время сбоя. Перед отправкой журналов удалите пароли, закрытые ключи, токены аутентификации и содержимое личных сообщений.

Практическая цель состоит в том, чтобы выявить первую неисправную зависимость, внести одно соответствующее версии исправление и проверить поведение службы как на уровне процесса, так и на уровне пользователя. Такой подход помогает восстановить работу почтовой службы, снижая при этом риск превращения одного остановленного компонента в более масштабный сбой.