Stan Zimbra zmcontrol pokazuje zatrzymanie usług hosta: przewodnik rozwiązywania problemów

Hipotetyczny przykład: Alex, administrator serwera Zimbra w małej firmie, otrzymuje raporty o niedostępności poczty internetowej po rutynowej konserwacji hosta. Z serwera Alex uruchamia zmcontrol statusi widzi mailbox Stopped, podczas gdy LDAP i MTA pokazują Running. Jest to scenariusz poglądowy, a nie raport o rzeczywistej awarii ani test. Najważniejszym krokiem jest znalezienie błędu uruchamiania uszkodzonego komponentu przed ponownym uruchomieniem całego stosu lub usunięciem plików.

zmcontrol statusRaportuje stan usługi rozpoznany przez zainstalowany host Zimbra. Zatrzymana usługa to objaw, a nie diagnoza: przyczyną może być pełny system plików, awaria zależności, konflikt portów, awaria procesu lub problem specyficzny dla danej wersji. Nazwy i role usług różnią się w zależności od wersji Zimbra oraz wdrożeń na jednym lub wielu serwerach. Odniesienia do poleceń dostępne w Centrum Technicznym Zimbra zawierają starsze i archiwalne materiały, dlatego należy ich używać do podstawowej orientacji i weryfikacji wszelkich działań naprawczych z dokumentacją lub pomocą techniczną dla zainstalowanej wersji. Niniejszy podręcznik został sprawdzony pod kątem oficjalnych odniesień do Zimbra 6 października 2026 r.

1. Zanim cokolwiek zmienisz, zapisz, co zostało zatrzymane

Zaloguj się do odpowiedniego hosta Zimbra, zostań użytkownikiem systemu operacyjnego Zimbra i zapisz wersję produktu oraz pełne dane wyjściowe dotyczące statusu:

su - zimbra
zmcontrol -v
zmcontrol status

Zapisz dane wyjściowe i zanotuj godzinę sprawdzenia. W hipotetycznym przypadku Alexa kluczowym szczegółem jest to, że skrzynka pocztowa jest zatrzymana, ale LDAP i MTA są zgłaszane jako działające. Jeśli kilka komponentów jest zatrzymanych, zanotuj ich kolejność i czy problem został poprzedzony niedawną aktualizacją, ponownym uruchomieniem, zmianą certyfikatu, zdarzeniem związanym z magazynem lub edycją konfiguracji. W przypadku wdrożenia wieloserwerowego sprawdź stan na każdym hoście, którego dotyczy problem; węzeł skrzynki pocztowej, węzeł LDAP i węzeł MTA mają różne role i zależności.

W dokumentacji poleceń Zimbra opisano zmcontrol statuswyświetlanie stanów Uruchomione lub Zatrzymane dla komponentów, ale podane przykłady pochodzą ze starszych wersji ZCS. Aktualne dane wyjściowe na serwerze to odpowiedni inwentarz. Przed zastosowaniem procedur specyficznych dla danej wersji zapoznaj się z dokumentacją Zimbra zmcontrol i sprawdź jej kategorie oraz kontekst wersji.

2. Sprawdź ostatnie logi pod kątem pierwszej awarii

Poszukaj błędów z tego samego momentu, w którym usługa została zatrzymana. W przypadku typowej instalacji pakietowej przydatne lokalizacje obejmują /var/log/zimbra.logpliki i /opt/zimbra/log. Dokładna zawartość logów zależy od wersji Zimbra i włączonych usług.

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

Uruchamiaj polecenia z konta, które może odczytywać pliki; używaj ich sudotylko w razie potrzeby. Szukaj najwcześniejszego konkretnego błędu, a nie tylko powtarzających się komunikatów o zatrzymaniu usługi. Przykładami mogą być: „Brak miejsca na urządzeniu”, błąd powiązania lub użycia adresu, nieudane połączenie LDAP, błąd połączenia z bazą danych, błąd uprawnień lub wyjście z procesu Java. Późniejsza kaskada błędów może po prostu odzwierciedlać wcześniejszą awarię zależności.

Jeśli Alex mailbox.logpokazuje, że mailboxd nie mógł połączyć się z LDAP, następnym krokiem jest diagnoza łączności LDAP zamiast wielokrotnego restartowania mailboxd. Strona rozwiązywania problemów Zimbra zawiera listę typowych logów serwera, w tym mailbox.log, zimbra.log, nginx.logi zmmailboxd.out, oraz zaleca zbieranie fragmentów istotnych dla czasu podczas eskalacji problemu. Zapoznaj się z poradnikiem Zimbra dotyczącym rozwiązywania problemów i gromadzenia logów .

3. Wyklucz problemy na poziomie hosta

Przed próbą uruchomienia sprawdź zasoby i podstawową tożsamość hosta. Te testy tylko do odczytu mogą szybko ujawnić typowe przyczyny problemów w systemie operacyjnym:

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

Jeśli wolumin danych lub logów Zimbra jest pełny, zwolnij miejsce za pomocą standardowych procedur retencji i pojemności systemu; nie usuwaj bezmyślnie magazynów wiadomości, plików bazy danych ani logów. Wyczerpanie limitu inodów może uniemożliwić tworzenie nowych plików, nawet gdy system plików wydaje się mieć wolne miejsce. Niedobór pamięci lub nietypowo wysokie obciążenie mogą również uniemożliwić niezawodne uruchamianie usług pocztowych opartych na Javie.

Upewnij się, że w pełni kwalifikowana nazwa hosta jest rozpoznawana zgodnie z oczekiwaniami dla Twojego wdrożenia. Jeśli nazwa hosta lub rekord DNS uległy zmianie, porównaj je ze skonfigurowaną nazwą serwera i innymi węzłami Zimbra. Sprawdź również ostatnie aktualizacje pakietów, odnowienia certyfikatów, zmiany w zaporze sieciowej i montowania pamięci masowej. Jeśli serwer został ponownie uruchomiony, sprawdź, czy wymagane woluminy danych zostały zamontowane przed uruchomieniem usług.

4. Rozwiązywanie problemów w kolejności zależności

Zacznij od najwcześniejszej zależności widocznej w logach lub zatrzymanej w danych wyjściowych statusu. LDAP jest szczególnie ważny, ponieważ komponenty Zimbra wykorzystują informacje o katalogu do konfiguracji i uwierzytelniania. Jeśli LDAP nie działa, usługi podrzędne mogą przestać działać, nawet jeśli ich własne pliki i procesy wydają się nienaruszone. Sprawdź wpisy związane z LDAP w [usłudze] zimbra.log, potwierdź rozpoznawanie hosta i łączność między węzłami oraz upewnij się, że wolumin danych LDAP jest zamontowany i możliwy do zapisu. Nie próbuj odzyskiwania bazy danych ani odbudowywania danych katalogu na podstawie ogólnej listy kontrolnej; takie działania mogą spowodować utratę danych i muszą być zgodne z wersją produktu i stanem kopii zapasowej.

Jeśli LDAP jest sprawny, ale mailboxzostał zatrzymany, sprawdź mailbox.logi zmmailboxd.out. Sprawdź miejsce na dysku, dostępną pamięć oraz czy inny proces jest właścicielem portu lub adresu potrzebnego mailboxd. Administrator może sprawdzić gniazda nasłuchujące za pomocą:

sudo ss -ltnp

Porównaj dane wyjściowe z portami skonfigurowanymi w tej instalacji. Unikaj zatrzymywania niepowiązanego serwera WWW tylko dlatego, że historyczna strona rozwiązywania problemów wspomina o konflikcie portów; najpierw zidentyfikuj proces i upewnij się, że można go bezpiecznie zatrzymać. Starsza strona rozwiązywania problemów z pocztą Zimbra dokumentuje schemat nieudanego uruchomienia skrzynki pocztowej, ale sama jest oznaczona jako zarchiwizowana i nieobsługiwana w nowszych wersjach. Potraktuj to jako przykład objawu, a nie uniwersalną procedurę naprawy: zarchiwizowane notatki dotyczące rozwiązywania problemów z pocztą Zimbra .

Jeśli mtajest zatrzymany, sprawdź błędy przesyłania poczty zimbra.logi upewnij się, że host MTA może połączyć się ze skonfigurowaną usługą LDAP. Rola MTA obejmuje odbieranie i przekazywanie poczty, a wiadomości w kolejce mogą pozostać odroczone, gdy dostarczanie jest niedostępne. Sprawdź kolejkę dopiero po potwierdzeniu odpowiednich poleceń dla swojego wydania; nie opróżniaj, nie usuwaj ani nie ponownie kolejkuj wiadomości w pierwszej kolejności. Przegląd MTA Zimbra wyjaśnia relacje między Postfixem, LDAP oraz kolejkami przychodzącymi, aktywnymi, odroczonymi i oczekującymi: Przegląd architektury i kolejek MTA Zimbra .

5. Wypróbuj kontrolowany start usługi

Po zebraniu dowodów i usunięciu zidentyfikowanej przyczyny na poziomie hosta, uruchom usługi za pomocą polecenia obsługiwanego przez zainstalowaną wersję i rolę serwera. W standardowych instalacjach Zimbra Collaboration administratorzy zazwyczaj uruchamiają komendy zmcontrol startjako użytkownik Zimbra:

su - zimbra
zmcontrol start

Obserwuj dane wyjściowe dla każdego komponentu. Jeśli usługa zgłasza błąd FAILED, zapisz dokładny komunikat i zaprzestań powtarzania tej samej próby uruchomienia, dopóki nie sprawdzisz odpowiedniego dziennika. Polecenie uruchomienia może ujawnić przydatne błędy, ale wielokrotne restarty mogą ukryć pierwotną awarię lub przerwać działanie komponentów, które nadal obsługują użytkowników. Unikaj uruchamiania poleceń o szerokim zakresie stop, shutdownlub restartpodczas aktywnego incydentu, chyba że masz okno konserwacyjne i rozumiesz wpływ na każdy węzeł.

Nie usuwaj plików PID, nie zabijaj procesów za pomocą kill -9, nie modyfikuj wygenerowanej konfiguracji Postfix ani nie uruchamiaj poleceń naprawy LDAP/bazy danych tylko dlatego, że wymieniono je na starej stronie wiki. Takie kroki są w dużym stopniu zależne od stanu procesu i wersji oprogramowania. Najpierw sprawdź, czy proces rzeczywiście został porzucony, postępuj zgodnie z procedurą producenta dla danej wersji i upewnij się, że istnieje aktualna kopia zapasowa. Publiczne strony rozwiązywania problemów Zimbra różnią się wiekiem, a niektóre z nich zawierają wyraźne powiadomienia o archiwach lub pracach w toku.

6. Użyj wyjścia statusu, aby zawęzić następną akcję

• Protokół LDAP został zatrzymany, kilka usług zostało zatrzymanych: przed diagnozowaniem usług podrzędnych należy zbadać własny dziennik uruchamiania LDAP, DNS, rozwiązywanie nazw hostów, wolumen danych i łączność między węzłami.
• Skrzynka pocztowa została zatrzymana, LDAP działa: użyj dzienników skrzynki pocztowej, kontroli pamięci i dysku hosta oraz inspekcji nasłuchiwacza, aby znaleźć pierwszą awarię mailboxd.
• MTA zatrzymane, skrzynka pocztowa działa: sprawdź logi MTA, dostępność LDAP, błędy generowania konfiguracji i to, czy serwer może powiązać skonfigurowane programy nasłuchujące SMTP.
• Zatrzymany jest tylko rejestrator, statystyki, moduł antyspamowy lub antywirusowy: określ, czy dany komponent jest wymagany dla przepływu poczty, którego dotyczy problem, na tym serwerze. Jego stan może wpływać na monitorowanie lub filtrowanie, nie powodując awarii poczty internetowej.
• Wszystkie komponenty mają status „Uruchomione”, ale użytkownicy nadal nie mogą się połączyć: sprawdź serwer proxy, zewnętrzny moduł równoważenia obciążenia, DNS, zaporę sieciową, certyfikat TLS i odpowiedni punkt końcowy skierowany do klienta. „Uruchomiony” proces nie dowodzi, że klienci mogą uzyskać dostęp do usługi.

W hipotetycznym przykładzie Alex nie powinien wnioskować, że cały serwer Zimbra jest sprawny tylko dlatego, że LDAP i MTA są uruchomione; skrzynka pocztowa pozostaje bezpośrednią przyczyną niedostępności poczty internetowej. Jeśli logi skrzynki pocztowej wskazują na LDAP pomimo jej stanu Uruchomiono, należy przetestować skonfigurowane połączenie między tymi usługami, zamiast polegać wyłącznie na etykiecie podsumowującej.

7. Potwierdź odzyskiwanie z punktu widzenia użytkownika

Po próbie uruchomienia uruchom zmcontrol statusponownie i upewnij się, że poprzednio zatrzymana usługa zgłasza stan „Uruchomiona”. Następnie sprawdź dziennik usługi pod kątem nowych błędów uruchamiania. Status pomyślny jest konieczny, ale niewystarczający: sprawdź, czy administratorzy mogą uzyskać dostęp do interfejsu internetowego, czy autoryzowane konto testowe może się zalogować, a oczekiwany przepływ poczty działa. W przypadku incydentu MTA sprawdź, czy nowe wiadomości przychodzące i wychodzące są dostarczane oraz czy kolejka się zmniejsza, a nie powiększa.

W przykładzie Alexa, odzyskiwanie oznacza, że ​​skrzynka pocztowa pozostaje w trybie „Uruchomiona” po uruchomieniu, logi skrzynki pocztowej nie pokazują już pierwotnego błędu zależności ani powiązania, a użytkownik testowy może uzyskać dostęp do poczty internetowej. Jeśli status powróci do „Zatrzymany”, zachowaj nowe dane wyjściowe uruchomienia i odpowiadające im fragmenty logu zamiast powtarzać restarty. Ten dowód pomaga odróżnić trwały błąd zależności od procesu, który uruchamia się, a następnie ulega awarii.

Kiedy eskalować

Skontaktuj się z pomocą techniczną Zimbra lub administratorem odpowiedzialnym za wdrożenie, jeśli LDAP nie uruchamia się, występuje błąd integralności bazy danych lub katalogu, usługa wielokrotnie ulega awarii, system jest klastrem wielowęzłowym o niespójnym stanie lub następna proponowana czynność obejmuje usunięcie danych lub zmianę wygenerowanej konfiguracji. Dołącz wersję i kompilację Zimbra, wersję systemu operacyjnego, rolę i topologię serwera, dokładne zmcontrol statusdane wyjściowe, historię ostatnich zmian oraz fragmenty logów obejmujące czas awarii. Przed udostępnieniem logów usuń hasła, klucze prywatne, tokeny uwierzytelniające i treść wiadomości osobistych.

Praktycznym celem jest zidentyfikowanie pierwszej niedziałającej zależności, wprowadzenie jednej poprawki odpowiedniej dla danej wersji oraz weryfikacja działania usługi zarówno na poziomie procesu, jak i użytkownika. Takie podejście pomaga przywrócić usługę pocztową, jednocześnie zmniejszając ryzyko przekształcenia pojedynczego, niedziałającego komponentu w poważniejszą awarię.