Starea Zimbra zmcontrol arată că serviciile gazdă sunt oprite: Ghid de depanare

Exemplu ipotetic: Alex, administratorul serverului Zimbra al unei mici companii, primește rapoarte conform cărora webmail-ul nu este disponibil după o fereastră de mentenanță de rutină a gazdei. De pe server, Alex rulează zmcontrol statusși vede mailbox Stopped, în timp ce LDAP și MTA afișează Running. Acesta este un scenariu ilustrativ, nu un raport al unei întreruperi sau al unui test real. Prima mișcare importantă este găsirea erorii de pornire a componentei defecte înainte de a reporni întreaga stivă sau de a șterge fișiere.

zmcontrol statusraportează starea serviciului recunoscută de gazda Zimbra instalată. Un serviciu oprit este un simptom, nu un diagnostic: cauza ar putea fi un sistem de fișiere plin, o dependență eșuată, un conflict de porturi, o prăbușire a procesului sau o problemă specifică versiunii. Numele și rolurile serviciilor variază în funcție de versiunile Zimbra și de implementările pe un singur server sau pe mai multe servere. Referințele comenzilor disponibile în Centrul Tehnic Zimbra includ materiale mai vechi și arhivate, așadar folosiți-le pentru orientare de bază și verificați orice operațiune corectivă în raport cu documentația sau asistența pentru versiunea instalată. Acest ghid a fost verificat în raport cu referințele oficiale Zimbra pe 6 octombrie 2026.

1. Înregistrați ce este oprit înainte de a schimba ceva

Conectați-vă la gazda Zimbra afectată, deveniți utilizatorul sistemului de operare Zimbra și înregistrați versiunea produsului și starea completă a rezultatului:

su - zimbra
zmcontrol -v
zmcontrol status

Salvați rezultatul și notați ora verificării. În cazul ipotetic al lui Alex, detaliul cheie este că cutia poștală este oprită, dar LDAP și MTA sunt raportate ca rulând. Dacă mai multe componente sunt oprite, notați ordinea lor și dacă o actualizare recentă, o repornire, o modificare a certificatului, un eveniment de stocare sau o editare a configurației a precedat problema. Într-o implementare pe mai multe servere, rulați verificarea stării pe fiecare gazdă afectată; un nod de cutie poștală, un nod LDAP și un nod MTA au roluri și dependențe diferite.

Referința comenzilor Zimbra descrie zmcontrol statusafișarea stărilor „Runing” sau „Stopped” pentru componente, dar exemplele listate provin din versiuni mai vechi de ZCS. Ieșirea curentă de pe server este inventarul relevant. Consultați referința Zimbra zmcontrol și verificați categoriile și contextul versiunii înainte de a aplica proceduri specifice versiunii.

2. Verificați jurnalele recente pentru prima eroare

Căutați erori din momentul în care serviciul s-a oprit. Pentru o instalare tipică în pachet, locațiile utile includ /var/log/zimbra.logfișierele și fișierele de sub /opt/zimbra/log. Jurnalele exacte prezente depind de versiunea de Zimbra și de serviciile activate.

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

Executați comenzi cu un cont care poate citi fișiere; utilizați-le sudodoar acolo unde este necesar. Căutați cea mai veche eroare specifică, nu doar mesajele repetate de tip „serviciu oprit”. Exemplele includ „Nu există spațiu rămas pe dispozitiv”, o eroare de legare sau adresă în uz, o conexiune LDAP eșuată, o eroare de conexiune la baza de date, o eroare de permisiune sau o ieșire a unui proces Java. O cascadă ulterioară de eșecuri poate reflecta pur și simplu o dependență anterioară care a eșuat mai întâi.

Pentru Alex, dacă mailbox.logarată că mailboxd nu s-a putut conecta la LDAP, următorul pas este diagnosticarea conectivității LDAP, în loc să repornească în mod repetat mailboxd. Pagina de depanare Zimbra listează jurnalele comune ale serverului, inclusiv mailbox.log, zimbra.log, nginx.log, și zmmailboxd.out, și recomandă colectarea extraselor relevante în timp atunci când escaladați o problemă. Consultați îndrumările Zimbra privind depanarea și colectarea jurnalelor .

3. Excludeți problemele la nivel de gazdă

Înainte de a încerca o pornire, verificați resursele și identitatea de bază a gazdei. Aceste verificări doar în citire pot dezvălui rapid cauze comune ale sistemului de operare:

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

Dacă un volum de date sau jurnal Zimbra este plin, eliberați spațiu prin procedurile normale de retenție și capacitate ale sistemului; nu eliminați orbește depozitele de mesaje, fișierele bazei de date sau jurnalele. Un număr de inode-uri epuizat poate împiedica crearea de fișiere noi, chiar și atunci când un sistem de fișiere pare să aibă capacitate liberă. Memoria redusă sau încărcarea neobișnuit de mare pot, de asemenea, împiedica pornirea fiabilă a serviciilor de cutie poștală bazate pe Java.

Confirmați că numele complet calificat al gazdei se rezolvă conform așteptărilor pentru implementarea dvs. Dacă un nume de gazdă sau o înregistrare DNS s-a modificat, comparați-l cu numele configurat al serverului și cu celelalte noduri Zimbra. Verificați, de asemenea, actualizările recente ale pachetelor, reînnoirile certificatelor, modificările firewall-ului și montările spațiului de stocare. Dacă serverul a fost repornit, verificați dacă volumele de date necesare au fost montate înainte de a porni serviciile.

4. Depanarea în ordinea dependenței

Începeți cu cea mai veche dependență afișată în jurnale sau oprită în ieșirea de stare. LDAP este deosebit de important deoarece componentele Zimbra utilizează informații despre director pentru configurare și autentificare. Dacă LDAP este nefuncțional, serviciile din aval pot eșua chiar și atunci când propriile fișiere și procese par intacte. Verificați intrările legate de LDAP din zimbra.log, confirmați rezoluția gazdei și conectivitatea dintre noduri și verificați dacă volumul de date LDAP este montat și are permisiunea de scriere. Nu încercați recuperarea bazei de date sau reconstruirea datelor din director pe baza unei liste de verificare generice; aceste acțiuni pot cauza pierderi de date și trebuie să corespundă versiunii produsului și stării copiei de rezervă.

Dacă LDAP este funcțional, dar mailboxeste oprit, inspectați mailbox.logși zmmailboxd.out. Verificați spațiul pe disc, memoria disponibilă și dacă un alt proces deține portul sau adresa de care are nevoie mailboxd. Un administrator poate inspecta socket-urile de ascultare cu:

sudo ss -ltnp

Comparați rezultatul cu porturile configurate în această instalare. Evitați oprirea unui server web fără legătură doar pentru că o pagină de depanare istorică menționează un conflict de porturi; identificați mai întâi procesul și confirmați că este sigur să îl opriți. Pagina mai veche de depanare a cutiei poștale Zimbra documentează un model de eroare de pornire a cutiei poștale, dar se etichetează ca arhivată și neacceptată pentru versiunile recente. Tratați-o ca un exemplu de simptom, nu ca o procedură de reparare universală: note de depanare a cutiei poștale Zimbra arhivate .

Dacă mtaeste oprit, inspectați erorile de transfer de e-mail zimbra.logși confirmați că gazda MTA poate accesa serviciul LDAP configurat. Rolul MTA include primirea și retransmiterea e-mailurilor, iar mesajele din coadă pot rămâne amânate cât timp livrarea nu este disponibilă. Inspectați coada numai după confirmarea comenzilor corespunzătoare pentru lansare; nu goliți, ștergeți și nu repuneți mesajele în coadă ca prim răspuns. Prezentarea generală a MTA a Zimbra explică relația dintre Postfix, LDAP și cozile de intrare, active, amânate și de așteptare: Arhitectura și prezentarea generală a cozii Zimbra MTA .

5. Încercați o pornire controlată a serviciului

După ce ați capturat dovezile și ați corectat o cauză identificată la nivel de gazdă, porniți serviciile utilizând comanda acceptată de versiunea instalată și rolul de server. În instalările standard de Zimbra Collaboration, administratorii rulează de obicei zmcontrol startca utilizator Zimbra:

su - zimbra
zmcontrol start

Urmăriți rezultatul pentru fiecare componentă. Dacă un serviciu raportează FAILED, înregistrați mesajul exact și opriți repetarea aceleiași încercări de pornire până când ați examinat jurnalul corespunzător. O comandă de pornire poate expune erori utile, dar repornirile repetate pot ascunde eroarea inițială sau pot întrerupe componentele care încă deservesc utilizatorii. Evitați rularea comenzilor largi stop, shutdown, sau restartîn timpul unui incident activ, cu excepția cazului în care aveți o fereastră de întreținere și înțelegeți impactul asupra fiecărui nod.

Nu ștergeți fișierele PID, nu închideți procesele cu kill -9, nu modificați configurația Postfix generată și nu rulați comenzi de reparare LDAP/baza de date doar pentru că sunt listate pe o pagină wiki veche. Astfel de pași depind în mare măsură de starea procesului și de versiunea software-ului. Mai întâi verificați dacă un proces este într-adevăr orfan, urmați procedura exactă a furnizorului specifică versiunii și asigurați-vă că există o copie de rezervă actualizată. Paginile publice de depanare ale Zimbra variază în funcție de vechime, iar unele conțin în mod explicit notificări de arhivă sau de lucru în curs.

6. Folosește ieșirea de stare pentru a restrânge următoarea acțiune

• LDAP s-a oprit, mai multe servicii s-au oprit: investigați jurnalul de pornire propriu al LDAP, DNS-ul, rezoluția numelui de gazdă, volumul de date și conectivitatea internodurilor înainte de a diagnostica serviciile din aval.
• Cutie poștală oprită, LDAP rulează: utilizați jurnalele cutiei poștale, verificările memoriei gazdă și ale discului și inspecția ascultătorilor pentru a căuta prima eroare mailboxd.
• MTA oprit, cutia poștală rulează: verificați jurnalele MTA, accesibilitatea LDAP, erorile de generare a configurației și dacă serverul poate lega listenerele SMTP configurate.
• Doar jurnalul de e-mailuri, statisticile, antispam-ul sau antivirusul sunt oprite: determinați dacă acea componentă este necesară pentru fluxul de e-mailuri afectat de pe acest server. Starea sa poate afecta monitorizarea sau filtrarea fără a explica o întrerupere a serviciului webmail.
• Toate componentele afișează Running, dar utilizatorii tot nu se pot conecta: verificați proxy-ul web, echilibratorul de sarcină extern, DNS-ul, firewall-ul, certificatul TLS și endpoint-ul relevant orientat către client. Un proces Running nu dovedește că clienții pot accesa serviciul.

În exemplul ipotetic, Alex nu ar trebui să concluzioneze că întregul server Zimbra este sănătos doar pentru că LDAP și MTA rulează; cutia poștală rămâne motivul direct pentru care webmail-ul ar putea fi indisponibil. Dacă jurnalele cutiei poștale indică LDAP în ciuda stării sale „Runing”, testați conexiunea configurată între aceste servicii, în loc să vă bazați doar pe eticheta de rezumat.

7. Confirmați recuperarea din punctul de vedere al utilizatorului

După încercarea de pornire, rulați zmcontrol statusdin nou și confirmați că serviciul oprit anterior raportează „În funcțiune”. Apoi, verificați jurnalul propriu al serviciului pentru erori de pornire proaspătă. O stare de succes este necesară, dar nu suficientă: verificați dacă administratorii pot accesa interfața web, dacă un cont de test autorizat se poate conecta și dacă fluxul de e-mail așteptat funcționează. Pentru un incident MTA, confirmați că mesajele noi de intrare și de ieșire sunt livrate și că coada se epuizează în loc să crească.

În exemplul lui Alex, recuperarea înseamnă că cutia poștală rămâne în funcțiune după pornire, jurnalele cutiei poștale nu mai afișează eroarea originală de dependență sau de legare, iar un utilizator de test poate accesa webmail-ul. Dacă starea revine la Oprit, se păstrează noua ieșire de pornire și extrasele de jurnal corespunzătoare în loc să se parcurgă repornirile. Aceste dovezi ajută la distingerea unei erori persistente de dependență de un proces care pornește și apoi se blochează.

Când să escaladeze

Contactați Asistența Zimbra sau administratorul responsabil pentru implementare dacă LDAP nu pornește, apare o eroare de integritate a bazei de date sau a directorului, un serviciu se blochează în mod repetat, sistemul este un cluster cu mai multe noduri cu o stare inconsistentă sau următoarea acțiune propusă implică ștergerea datelor sau modificarea configurației generate. Includeți versiunea și compilarea Zimbra, versiunea sistemului de operare, rolul serverului și topologia, zmcontrol statusieșirea exactă, istoricul modificărilor recente și extrase din jurnal care acoperă timpul de eroare. Redactați parolele, cheile private, token-urile de autentificare și conținutul mesajelor personale înainte de a partaja jurnalele.

Scopul practic este de a identifica prima dependență eșuată, de a face o corecție corespunzătoare versiunii și de a verifica comportamentul serviciului atât la nivel de proces, cât și la nivel de utilizator. Această abordare ajută la restaurarea serviciului de e-mail, reducând în același timp riscul de a transforma o singură componentă oprită într-o întrerupere mai amplă.