Zimbra zmcontrol 상태 보고서에 호스트 서비스가 중지되었다고 표시되는 경우: 문제 해결 가이드

가상 예시: 소규모 회사의 Zimbra 서버 관리자인 Alex는 정기적인 호스트 유지 관리 시간 이후 웹메일을 사용할 수 없다는 보고를 받았습니다. 서버에서 Alex는 명령어를 실행하여 오류를 zmcontrol status확인하고 mailbox Stopped, LDAP 및 MTA에서는 오류가 발생하는 것을 확인 Running했습니다. 이는 실제 장애 또는 테스트 상황이 아닌, 문제 해결을 위한 예시 시나리오입니다. 가장 중요한 첫 번째 단계는 전체 스택을 재시작하거나 파일을 삭제하기 전에 오류가 발생한 구성 요소의 시작 오류를 찾는 것입니다.

zmcontrol status이 보고서는 설치된 Zimbra 호스트에서 인식하는 서비스 상태를 나타냅니다. 서비스가 중지되었다는 것은 증상일 뿐 진단은 아닙니다. 원인은 파일 시스템 용량 부족, 종속성 오류, 포트 충돌, 프로세스 충돌 또는 버전별 문제일 수 있습니다. 서비스 이름과 역할은 Zimbra 버전과 단일 서버 또는 다중 서버 배포 환경에 따라 다릅니다. Zimbra 기술 센터에서 제공하는 명령 참조 자료에는 이전 버전 및 보관된 자료가 포함되어 있으므로 기본적인 사용법을 익히는 데 사용하고, 수정 작업은 설치된 릴리스에 대한 문서 또는 지원 자료를 통해 확인하십시오. 이 가이드는 2026년 10월 6일에 Zimbra 공식 참조 자료를 기준으로 검토되었습니다.

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 프로세스 종료 등이 있습니다. 이후에 발생하는 일련의 오류는 단순히 이전에 발생한 종속성 오류가 원인일 수 있습니다.

Alex의 경우, mailbox.logmailboxd가 LDAP에 연결할 수 없다는 메시지가 표시되면 mailboxd를 반복적으로 재시작하기보다는 LDAP 연결 문제를 진단하는 것이 다음 단계입니다. Zimbra의 문제 해결 페이지에는 일반적인 서버 로그(예: mailbox.log, zimbra.log, nginx.log, zmmailboxd.out)가 나열되어 있으며, 문제 발생 시 관련 시간대의 로그를 수집할 것을 권장합니다. Zimbra의 문제 해결 및 로그 수집 지침을 참조하십시오 .

3. 호스트 수준의 문제를 배제하십시오.

시작하기 전에 리소스와 기본 호스트 ID를 확인하십시오. 이러한 읽기 전용 검사를 통해 일반적인 운영 체제 문제를 신속하게 파악할 수 있습니다.

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. 종속성 순서대로 문제를 해결하십시오.

로그에 표시되거나 상태 출력에서 ​​중지된 가장 오래된 종속성부터 시작하십시오. Zimbra 구성 요소는 구성 및 인증에 디렉터리 정보를 사용하므로 LDAP가 특히 중요합니다. LDAP가 다운되면 하위 서비스의 파일과 프로세스는 정상적으로 보이더라도 다운스트림 서비스가 실패할 수 있습니다. 디렉터리에서 LDAP 관련 항목을 확인하고 zimbra.log, 호스트 이름 확인 및 노드 간 연결을 확인하고, LDAP 데이터 볼륨이 마운트되어 쓰기 가능한지 확인하십시오. 일반적인 체크리스트를 기반으로 데이터베이스 복구 또는 디렉터리 데이터 재구축을 시도하지 마십시오. 이러한 작업은 데이터 손실을 초래할 수 있으며 제품 버전 및 백업 상태와 일치해야 합니다.

LDAP이 정상 상태이지만 mailbox중지된 경우, 디스크 공간, 사용 가능한 메모리, 그리고 mailboxd에 필요한 포트 또는 주소를 다른 프로세스가 소유하고 있는지 확인하십시오. 관리자는 다음 명령을 사용하여 수신 대기 소켓을 확인할 수 있습니다 mailbox.log.zmmailboxd.out

sudo ss -ltnp

이 설치에 구성된 포트와 출력을 비교하십시오. 이전 문제 해결 페이지에서 포트 충돌을 언급했다는 이유만으로 관련 없는 웹 서버를 중지하지 마십시오. 먼저 해당 프로세스를 식별하고 중지해도 안전한지 확인하십시오. Zimbra의 이전 사서함 문제 해결 페이지에는 사서함 시작 실패 패턴이 설명되어 있지만, 최신 버전에서는 지원되지 않고 보관 처리되었다고 명시되어 있습니다. 해당 페이지는 일반적인 복구 절차가 아닌 증상 예시로만 간주하십시오. ( 보관된 Zimbra 사서함 문제 해결 참고 사항 참조 )

메일 전송이 중단된 경우 mta, 메일 전송 오류를 확인 zimbra.log하고 MTA 호스트가 구성된 LDAP 서비스에 연결할 수 있는지 확인하십시오. MTA는 메일 수신 및 중계 역할을 하며, 전송이 불가능한 동안에는 대기 중인 메시지가 지연될 수 있습니다. 사용 중인 버전에 맞는 명령어를 확인한 후에만 대기열을 검사하십시오. 첫 번째 조치로 메시지를 플러시하거나 삭제하거나 다시 대기열에 추가하지 마십시오. Zimbra의 MTA 개요에서는 Postfix, LDAP, 그리고 수신, 활성, 지연 및 보류 대기열 간의 관계를 설명합니다. (Zimbra MTA 아키텍처 및 대기열 개요 참조 )

5. 제어된 서비스 시작을 시도해 보세요.

증거를 확보하고 호스트 수준의 원인을 파악하여 수정했으면, 설치된 릴리스 및 서버 역할에서 지원하는 명령어를 사용하여 서비스를 시작하십시오. 일반적인 Zimbra Collaboration 설치 환경에서 관리자는 보통 zmcontrol startZimbra 사용자 계정으로 다음 명령어를 실행합니다.

su - zimbra
zmcontrol start

각 구성 요소의 출력을 주시하십시오. 서비스에서 오류가 보고되면 FAILED정확한 메시지를 기록하고 해당 로그를 검토할 때까지 동일한 시작 시도를 반복하지 마십시오. 시작 명령을 통해 유용한 오류를 확인할 수 있지만, 반복적인 재시작은 원래 오류를 가리거나 여전히 사용자에게 서비스를 제공하는 구성 요소에 장애를 일으킬 수 있습니다. 유지 관리 기간이 확보되어 있고 모든 노드에 미치는 영향을 정확히 파악하지 못한 경우, 장애 발생 중에는 광범위한 명령이나 stop명령어 를 실행하지 마십시오.shutdownrestart

오래된 위키 페이지에 나와 있다고 해서 PID 파일을 삭제하거나, 프로세스를 강제 종료하거나 kill -9, 생성된 Postfix 구성을 수정하거나, LDAP/데이터베이스 복구 명령을 실행하지 마십시오. 이러한 작업은 프로세스 상태와 소프트웨어 버전에 따라 크게 달라집니다. 먼저 프로세스가 실제로 고아 프로세스인지 확인하고, 해당 릴리스별 공급업체 절차를 정확히 따르고, 최신 백업이 있는지 확인하십시오. Zimbra의 공개 문제 해결 페이지는 작성 시기가 다양하며, 일부 페이지에는 보관 또는 작업 진행 중이라는 공지가 명시되어 있습니다.

6. 상태 출력 결과를 활용하여 다음 조치를 구체화합니다.

• LDAP가 중지되었고, 여러 서비스가 중지되었습니다. 하위 서비스 문제를 진단하기 전에 LDAP 자체 시작 로그, DNS, 호스트 이름 확인, 데이터 용량 및 노드 간 연결 상태를 조사하십시오.
• 사서함이 중지되었지만 LDAP는 실행 중입니다. 사서함 로그, 호스트 메모리 및 디스크 검사, 그리고 리스너 검사를 사용하여 첫 번째 mailboxd 오류를 찾으십시오.
• MTA가 중지되었지만 사서함은 실행 중입니다. MTA 로그, LDAP 연결 가능성, 구성 생성 오류 및 서버가 구성된 SMTP 수신자를 바인딩할 수 있는지 여부를 확인하십시오.
• 로거, 통계, 스팸 방지 또는 바이러스 백신 중 하나만 중지된 경우, 해당 구성 요소가 이 서버의 메일 흐름에 필요한지 확인하십시오. 해당 구성 요소의 상태는 웹메일 중단을 설명하지 않고도 모니터링 또는 필터링에 영향을 미칠 수 있습니다.
• 모든 구성 요소가 실행 중으로 표시되지만 사용자가 여전히 연결할 수 없는 경우 웹 프록시, 외부 로드 밸런서, DNS, 방화벽, TLS 인증서 및 관련 클라이언트 엔드포인트를 확인하십시오. 프로세스가 실행 중이라고 해서 클라이언트가 서비스에 연결할 수 있다는 것을 보장하는 것은 아닙니다.

가상의 예시에서, Alex는 LDAP와 MTA가 실행 중이라는 이유만으로 Zimbra 서버 전체가 정상이라고 결론지어서는 안 됩니다. 웹메일 접속 불가 문제는 여전히 사서함 문제로 인해 발생할 수 있습니다. 사서함 로그에 LDAP가 실행 중 상태로 표시되어 있더라도 LDAP 관련 문제가 나타난다면, 요약 레이블에만 의존하지 말고 해당 서비스 간의 연결된 상태를 테스트해야 합니다.

7. 사용자 관점에서 복구를 확인합니다.

시작 시도 후 zmcontrol status서비스를 다시 실행하여 이전에 중지되었던 서비스가 실행 중으로 표시되는지 확인하십시오. 그런 다음 서비스 자체 로그에서 새로운 시작 오류가 있는지 확인하십시오. 성공적인 상태 표시만으로는 충분하지 않습니다. 관리자가 웹 인터페이스에 접속할 수 있는지, 승인된 테스트 계정으로 로그인할 수 있는지, 예상되는 메일 흐름이 정상적으로 작동하는지 확인하십시오. MTA 관련 문제가 발생한 경우, 새로운 수신 및 발신 메시지가 전달되고 큐가 증가하는 대신 감소하는지 확인하십시오.

알렉스의 예시에서 복구란 사서함이 시작 후에도 실행 중 상태를 유지하고, 사서함 로그에 원래의 종속성 또는 바인딩 오류가 더 이상 표시되지 않으며, 테스트 사용자가 웹메일에 액세스할 수 있는 것을 의미합니다. 상태가 중지됨으로 되돌아가는 경우, 재시작을 반복하는 대신 새로운 시작 출력과 일치하는 로그 발췌 내용을 보존하십시오. 이러한 증거는 지속적인 종속성 오류와 프로세스가 시작되었다가 충돌하는 경우를 구분하는 데 도움이 됩니다.

언제 상황을 악화시켜야 할까요?

LDAP이 시작되지 않거나, 데이터베이스 또는 디렉터리 무결성 오류가 발생하거나, 서비스가 반복적으로 충돌하거나, 시스템이 상태가 일관되지 않은 다중 노드 클러스터이거나, 다음 조치로 데이터 삭제 또는 생성된 구성 변경이 필요한 경우 Zimbra 지원팀 또는 배포 담당 관리자에게 문의하십시오. 문의 시에는 Zimbra 버전 및 빌드, 운영 체제 버전, 서버 역할 및 토폴로지, 정확한 zmcontrol status출력 내용, 최근 변경 내역, 오류 발생 시점의 로그 발췌본을 제공해 주십시오. 로그를 공유하기 전에 암호, 개인 키, 인증 토큰 및 개인 메시지 내용은 삭제해 주시기 바랍니다.

실질적인 목표는 오류가 발생한 첫 번째 종속성을 식별하고, 버전에 맞는 수정 작업을 수행한 후, 프로세스 및 사용자 수준 모두에서 서비스 동작을 검증하는 것입니다. 이러한 접근 방식을 통해 메일 서비스를 복구하는 동시에 단일 구성 요소의 오류로 인한 서비스 중단이 더 광범위한 장애로 이어질 위험을 줄일 수 있습니다.