메일 저장소 문제 해결

이 절에서는 메일 저장소를 능동적으로 유지 관리하기 위한 지침을 제공합니다. 또한 이 절에서는 메일 저장소가 손상되었거나 예기치 않게 종료된 경우 사용할 수 있는 다른 메일 저장소 복구 절차에 대해 설명합니다. 이 추가 메일 저장소 복구 절차에 대한 절은 메일함 및 메일함 데이터베이스 복구를 확장한 것입니다.

이 절을 읽기 전에 이 장과 함께 Sun Java System Messaging Server Administration Reference의 명령줄 유틸리티 및 configutil에 대한 장을 검토하는 것이 좋습니다. 이 절은 다음 내용으로 구성되어 있습니다.

• 표준 메일 저장소 모니터링 절차

• 일반 문제 및 해결 방법

• 메일 저장소 시작 및 복구

• 메일함 및 메일함 데이터베이스 복구

표준 메일 저장소 모니터링 절차

이 절에서는 메일 저장소의 표준 모니터링 절차에 대해 개괄적으로 설명합니다. 이러한 절차는 일반적인 메일 저장소 검사, 테스트 및 표준 유지 관리에 유용합니다.

자세한 내용은 메일 저장소 모니터링을 참조하십시오.

하드웨어 공간 검사

메일 저장소에는 충분한 추가 디스크 공간과 하드웨어 자원이 있어야 합니다. 메일 저장소가 디스크 및 하드웨어 공간의 최대 한도에 가까이 도달하면 메일 저장소 내에 문제가 발생할 수 있습니다.

디스크 공간 부족은 메일 서버 문제 및 오류의 가장 일반적인 원인 중 하나입니다. 메일 저장소에 쓰기 위한 공간이 없을 경우 메일 서버에서 오류가 발생합니다. 또한 사용 가능한 디스크 공간이 일정한 임계값 아래로 내려가면 메일 전달, 로깅 등과 관련된 문제가 발생합니다. stored 프로세스의 정리 기능이 실패하고 삭제된 메일이 메일 저장소에서 정리되지 않으면 디스크 공간이 급속도로 줄어들 수 있습니다.

디스크 공간 모니터링에 대한 자세한 내용은 디스크 공간 모니터 및 메일 저장소 모니터링을 참조하십시오.

로그 파일 검사

로그 파일을 검사하여 메일 저장소 프로세스가 구성된 대로 실행되는지 확인합니다. Messaging Server는 지원되는 각각의 주요 프로토콜 또는 서비스(SMTP, IMAP, POP 및 HTTP)에 대한 별도의 로그 파일집합을 만듭니다. 이러한 로그 파일은 콘솔을 통해서나 msg_svr_base/log/ 디렉토리에서 확인할 수 있습니다. 정기적으로 로그 파일을 모니터해야 합니다.

로깅이 서버 성능에 영향을 줄 수 있다는 것을 유의하십시오. 더 자세한 로깅을 지정할수록 일정한 시간 동안 로그 파일이 차지하는 디스크 공간이 더 많아집니다. 따라서 효과적이면서 실제적인 로그 회전, 만료 및 백업 정책을 서버에 정의해야 합니다. 서버의 로깅 정책 정의에 대한 자세한 내용은 21 장, 로깅 관리을 참조하십시오.

원격 측정을 사용하여 사용자 IMAP/POP 세션 검사

Messaging Server는 사용자의 전체 IMAP, POP 또는 웹 메일 세션을 파일로 캡처할 수 있는 원격 측정이라는 기능을 제공합니다. 이 기능은 클라이언트 문제를 디버깅하는 데 유용합니다. 예를 들어, 사용자가 메일 액세스 클라이언트가 제대로 작동하지 않는다고 불평할 경우 이 기능을 사용하여 액세스 클라이언트와 Messaging Server 사이의 상호 작용을 추적할 수 있습니다.

세션을 캡처하려면 다음 디렉토리를 만들기만 하면 됩니다.

msg_svr_base/data/telemetry/pop_or_imap/userid

Messaging Server는 이 디렉토리에서 세션당 하나의 파일을 만듭니다. 출력 예는 다음과 같습니다.

LOGIN redb 2003/11/26 13:03:21
>0.017>1 OK User logged in
<0.047<2 XSERVERINFO MANAGEACCOUNTURL MANAGELISTSURL MANAGEFILTERSURL
>0.003>* XSERVERINFO MANAGEACCOUNTURL {67}
http://redb@cuisine.blue.planet.com:800/bin/user/admin/bin/enduser 
MANAGELISTSURL NIL MANAGEFILTERSURL NIL
2 OK Completed
<0.046<3 select "INBOX"
>0.236>* FLAGS (\Answered flagged draft deleted \Seen $MDNSent Junk)
* OK [PERMANENTFLAGS (\Answered flag draft deleted \Seen $MDNSent Junk \*)]
* 1538 EXISTS
* 0 RECENT
* OK [UNSEEN 23]
* OK [UIDVALIDITY 1046219200]
* OK [UIDNEXT 1968]
3 OK [READ-WRITE] Completed
<0.045<4 UID fetch 1:* (FLAGS)
>0.117>* 1 FETCH (FLAGS (\Seen) UID 330)
* 2 FETCH (FLAGS (\Seen) UID 331)
* 3 FETCH (FLAGS (\Seen) UID 332)
* 4 FETCH (FLAGS (\Seen) UID 333)
* 5 FETCH (FLAGS (\Seen) UID 334)
<etc>

stored 프로세스 검사

stored 함수는 메일 데이터베이스의 교착 상태 및 트랜잭션 작업, 에이징 정책 적용, 디스크에 저장된 메일 정리 및 삭제와 같은 여러 중요한 작업을 수행합니다. stored의 실행이 중지되면 Messaging Server에서 문제가 발생합니다. start-msg가 실행될 때 stored가 시작되지 않을 경우 다른 프로세스는 시작되지 않습니다.

• stored 프로세스가 실행 중인지 확인합니다. stored -t -v를 실행합니다.

• store_root/mboxlist에서 작성된 로그 파일을 확인합니다.

• 기본 로그 파일 msg_svr_base/log/default/default에서 stored 메일을 확인합니다.

• stored 프로세스에서 다음 기능 중 하나를 시도할 때마다 msg_svr_base/config/ 디렉토리에 있는 다음 파일의 타임스탬프가 업데이트되는지 확인합니다.

stored 프로세스에 대한 자세한 내용은 Sun Java System Messaging Server 6 2005Q4 Administration Reference의 stored 유틸리티 사용 장을 참조하십시오.

stored 함수 모니터링에 대한 자세한 내용은 메일 저장소 모니터링을 참조하십시오.

데이터베이스 로그 파일 검사

데이터베이스 로그 파일은 store_root/mboxlist 디렉토리에 있는 sleepycat 트랜잭션 검사점 지정 로그 파일을 나타냅니다. 로그 파일이 누적될 경우 데이터베이스 검사점 지정이 발생하지 않습니다. 일반적으로 단일 기간 동안 둘 또는 세 개의 데이터베이스 로그 파일이 존재합니다. 파일이 더 많이 있을 경우는 문제가 발생한 것일 수 있습니다.

사용자 폴더 검사

사용자 폴더를 검사하려는 경우 모든 사용자 폴더를 검토하고 오류를 보고하는 reconstruct -r -n(재귀적 수정 없음) 명령을 실행할 수 있습니다. reconstruct 명령에 대한 자세한 내용은 메일함 및 메일함 데이터베이스 복구를 참조하십시오.

코어 파일 검사

코어 파일은 프로세스가 예기치 않게 종료된 경우에만 존재합니다. 특히 메일 저장소에 문제가 있을 경우 이러한 파일을 검토하는 것이 중요합니다. Solaris에서는 coreadm을 사용하여 core 파일 위치를 구성합니다.

메일 저장소 시작 및 복구

메일 저장소 데이터는 메일, 색인 데이터 및 메일 저장소 데이터베이스로 구성됩니다. 이 데이터는 상당히 견고하지만 가끔 시스템에 메일 저장소 데이터 문제가 발생할 수 있습니다. 이러한 문제는 기본 로그 파일에서 나타나며 그 대부분이 항상 투명하게 수정됩니다. 아주 드물게 로그 파일의 오류 메시지가 reconstruct 유틸리티를 실행해야 한다는 것을 나타낼 수 있습니다. 또한 메일을 보호하기 위한 마지막 수단으로 메일 저장소 백업 및 복원에 설명된 백업 및 복원 프로세스가 사용됩니다. 이 절에서는 stored의 자동 시작 및 복구 프로세스를 중심으로 설명합니다.

메일 저장소는 이전에 관리자가 담당하던 많은 복구 작업을 자동화합니다. 이러한 작업은 시작 시에 메일 저장소 데몬 stored에 의해 수행되며 필요에 따라 데이터베이스 스냅샷 및 자동 고속 복구를 포함합니다. stored는 메일 저장소의 데이터베이스를 철저하게 검사하여 문제가 감지된 경우 이를 자동으로 복구합니다.

stored는 또한 상태 메시지를 통해 포괄적인 데이터베이스 상태 분석을 기본 로그에 제공하여 메일 저장소에 대해 수행된 복구 작업과 메일 저장소를 작동시키기 위한 자동 시도를 보고합니다.

자동 시작 및 복구—작동 원리

stored 데몬은 다른 메일 저장소 프로세스보다 먼저 시작됩니다. 이 데몬은 메일 저장소 데이터베이스를 초기화하고 필요한 경우 복구합니다. 메일 저장소 데이터베이스는 폴더, 할당량, 가입 및 메일 플래그 정보를 보관합니다. 데이터베이스는 로깅 및 트랜잭션 가능하여 이미 복구가 내장되어 있습니다. 또한 일부 데이터베이스 정보는 각 폴더의 메일 색인 영역에서 중복하여 복사됩니다.

데이터베이스는 상당히 견고하지만 가끔씩 손상될 수 있으며 stored는 대부분의 경우 이 문제를 투명하게 복구합니다. 그러나 stored를 다시 시작할 때마다 기본 로그 파일을 검사하여 추가 관리 개입이 필요하지 않은지 확인해야 합니다. 데이터베이스의 추가 재작성이 필요한 경우 로그 파일의 상태 메시지에 reconstruct를 실행하라는 내용이 나타납니다.

메일 저장소 데이터베이스를 열기 전에 stored는 무결성을 분석하고 경고 범주에 속하는 상태 메시지를 기본 로그로 보냅니다. 일부 메시지는 관리자에게 유용하며 다른 일부는 내부 분석에 사용되는 코딩된 데이터로 구성됩니다. stored는 문제를 감지하면 데이터베이스를 수정하고 재시작을 시도합니다.

데이터베이스가 열리면 stored는 나머지 서비스를 시작할 수 있다는 것을 알립니다. 자동 수정이 실패할 경우 기본 로그의 메시지는 수행할 작업을 지정합니다. reconstruct -m이 필요하다는 것을 지정하는 오류 메시지를 참조하십시오.

이전 릴리스에서는 stored에서 복구 프로세스를 구현하는 데 매우 오래 걸려서 관리자가 stored를 "중단"된 것으로 여기기도 했습니다. 이제 이러한 긴 복구 유형은 제거되었으며 stored는 1분 이내에 최종 상태를 확인해야 합니다. 그러나 stored가 스냅샷 복구와 같은 복구 기술을 사용해야 할 경우 프로세스는 몇 분 정도가 소요될 수 있습니다.

대부분의 경우 복구가 수행된 후에 데이터베이스는 최신 상태로 업데이트되며 다른 작업은 필요하지 않습니다. 그러나 일부 복구는 메일 저장소의 중복 데이터를 동기화하기 위해 reconstruct -m이 필요합니다. 이러한 내용도 기본 로그에 표시되므로 시작 후에 기본 로그를 모니터하는 것이 중요합니다. 메일 저장소가 시작되어 정상적으로 실행되는 것처럼 보이는 경우에도 reconstruct와 같은 요청된 모든 작업을 실행해야 합니다.

로그 파일을 읽어야 하는 또 다른 이유는 처음에 데이터베이스를 손상시킨 원인을 확인하는 데 있습니다. stored는 시스템상의 문제와 무관하게 메일 저장소를 사용하도록 설계되었지만 데이터베이스 손상이 숨겨진 더 큰 문제의 일부일 수 있으므로 그 원인을 확인하는 것이 필요합니다.

reconstruct -m이 필요하다는 것을 지정하는 오류 메시지

이 절에서는 reconstruct -m을 실행해야 하는 오류 메시지 유형에 대해 설명합니다.

오류 메시지가 메일함 오류를 나타내면 reconstruct <mailbox>를 실행합니다. 예:

"Invalid cache data for msg 102 in mailbox user/joe/INBOX. Needs reconstruct"

"Mailbox corrupted, missing fixed headers: user/joe/INBOX"

"Mailbox corrupted, start_offset beyond EOF: user/joe/INBOX"

오류 메시지가 데이터베이스 오류를 나타내면 reconstruct -m을 실행합니다. 예:

"Removing extra database logs. Run reconstruct -m soon after startup to resync redundant data"

"Recovering database from snapshot. Run reconstruct -m soon after startup to resync redundant data"

데이터베이스 스냅샷

스냅샷은 데이터베이스의 핫 백업으로 stored에서 손상된 데이터베이스를 몇 분 안에 투명하게 복원하기 위해 사용합니다. 이것은 다른 영역에 저장된 중복된 정보에 의존하는 reconstruct를 사용하는 것보다 훨씬 더 빠릅니다.

메일 저장소 데이터베이스 스냅샷—작동 원리

mboxlist 디렉토리에 있는 데이터베이스의 스냅샷은 기본적으로 24시간에 한 번씩 자동으로 생성됩니다. 스냅샷은 기본적으로 store 디렉토리의 하위 디렉토리에 복사됩니다. 언제든지 기본적으로 다섯 개의 스냅샷(라이브 데이터베이스 하나, 스냅샷 세 개, 데이터 베이스/제거된 복사본 하나)이 있습니다. 데이터베이스/제거된 복사본이 가장 최신 버전이며 mboxlist 데이터베이스 디렉토리의 removed 하위 디렉토리로 보내지는 데이터베이스의 긴급 복사본입니다.

현재 데이터베이스가 손상된 것으로 확인되어 복구 프로세스에서 이를 제거하기로 결정하면 stored는 가능한 경우 해당 데이터베이스를 removed 디렉토리로 이동합니다. 이렇게 하면 필요에 따라 데이터베이스를 분석할 수 있습니다.

데이터 이동은 일주일에 한 번만 발생합니다. 따라서 이미 데이터베이스 복사본이 있는 경우에는 stored에서 저장소를 만들 때마다 데이터베이스 복사본을 교체하지 않습니다. stored는 removed 디렉토리의 데이터가 1주일보다 오래된 경우에만 교체를 수행합니다. 이것은 문제가 있는 원래 데이터베이스가 계속적인 시작으로 인해 너무 빨리 대체되는 것을 방지합니다.

메일 저장소 데이터베이스 스냅샷 간격 및 위치 지정

결합된 데이터베이스와 스냅샷의 5배에 해당하는 공간이 있어야 합니다. 관리자는 스냅샷을 별개의 디스크에서 실행되도록 다시 구성하고 시스템 요구에 맞게 조정하는 것이 좋습니다.

stored가 시작 시에 데이터베이스 문제를 감지할 경우 최적의 스냅샷이 자동으로 복구됩니다. 세 개의 스냅샷 변수는 스냅샷 파일 위치, 스냅샷 촬영 간격, 저장되는 스냅샷 수 등과 같은 매개 변수를 설정할 수 있습니다. 이러한 configutil 매개 변수는 표 18–15에 나와 있습니다.

스냅샷 간격이 너무 작으면 시스템에 자주 부담을 주게 되며 데이터베이스의 문제가 스냅샷으로 복사될 가능성이 더 커집니다. 스냅샷 간격이 너무 크면 스냅샷을 가져왔을 때 갖고 있던 상태를 데이터베이스가 계속 보유하는 상황이 발생할 수 있습니다.

스냅샷 간격으로 1일이 권장되지만 시스템상에 문제가 수일 동안 지속되거나 문제가 존재하기 전의 시점으로 되돌아가려는 경우 일주일 이상의 간격이 유용할 수 있습니다.

stored는 데이터베이스를 모니터하여 데이터베이스가 완전하지 않다고 의심될 경우 최신 스냅샷을 거부하며 그 대신에 가장 안정적인 최신 스냅샷을 검색합니다. 하루 전의 스냅샷을 검색할 수 있다는 사실에도 불구하고 시스템은 보다 최신의 중복 데이터가 있는 경우 이를 사용하며 이전 스냅샷 데이터를 무시합니다.

따라서 스냅샷의 궁극적인 역할은 시스템을 가능한 최신 상태로 유지하고 데이터를 즉석에서 재작성하려고 시도하는 시스템의 나머지 부분에 대한 부담을 줄여 주는 것입니다.

메일함 및 메일함 데이터베이스 복구

하나 이상의 메일함이 손상되면 reconstruct 유틸리티를 사용하여 메일함 또는 메일함 데이터베이스를 다시 작성하고 모든 불일치를 복구할 수 있습니다.

reconstruct 유틸리티는 하나 이상의 메일함 또는 마스터 메일함 파일을 다시 작성하고 모든 불일치를 복구합니다. 이 유틸리티를 사용하면 메일 저장소에서 거의 모든 형태의 데이터 손상을 복구할 수 있습니다. reconstruct -m이 필요하다는 것을 지정하는 오류 메시지를 참조하십시오.

표 18–16에는 reconstruct 옵션이 나열되어 있습니다. 자세한 구문 및 사용 요구 사항에 대해서는 Sun Java System Messaging Server 6 2005Q4 Administration Reference의 reconstruct를 참조하십시오.

메일함 재작성

메일함을 다시 작성하려면 -r 옵션을 사용합니다. 다음 경우에 이 옵션을 사용해야 합니다.

• 메일함에 액세스하면 “System I/O error” 또는 “Mailbox has an invalid format” 오류 중 하나가 표시됩니다.

• 메일함에 액세스할 때 서버 충돌이 발생하는 경우

• 스풀 디렉토리에서 파일이 추가 또는 제거된 경우

reconstruct -r은 우선 일관성 검사를 실행합니다. 이 검사는 모든 일관성을 보고하며 문제가 감지된 경우에만 재작성을 수행합니다. 결과적으로 이 릴리스에서 reconstruct 유틸리티의 성능이 향상됩니다.

다음 예에 설명된 대로 reconstruct를 사용할 수 있습니다.

사용자 daphne에 속하는 메일함의 스풀 영역을 다시 작성하려면 다음 명령을 사용합니다.

reconstruct -r user/daphne

메일함 데이터베이스에 나열된 모든 메일함의 스풀 영역을 다시 작성하려면 다음 명령을 사용합니다.

reconstruct -r

대용량 메일 저장소의 경우 메일함 데이터베이스에 나열된 모든 메일함의 스풀 영역을 다시 작성하는 것이 아주 오래 걸릴 수 있으므로 이 옵션은 신중하게 사용해야 합니다. reconstruct 성능을 참조하십시오. 저장소에 여러 디스크를 사용하는 것이 보다 나은 오류 복구 방법일 수 있습니다. 디스크가 하나가 중지되었다고 전체 저장소가 중지되지는 않습니다. 디스크가 손상된 경우 다음과 같이 -p 옵션을 사용하여 저장소의 일부만 다시 작성하면 됩니다.

reconstruct -r -p subpartition

primary 분할 영역에 있을 경우에만 명령줄 인수에 나열된 메일함을 다시 작성하려면 다음 명령을 수행합니다.

reconstruct -p primary mbox1 mbox2 mbox3

primary 분할 영역에 있는 모든 메일함을 다시 작성할 필요가 없을 경우 다음 명령을 사용합니다.

reconstruct -r -p primary

reconstruct를 실행하여 일관성 검사를 수행하지 않고 폴더를 다시 작성하려면 -f 옵션을 사용합니다. 예를 들어, 다음 명령을 실행하여 사용자 폴더 daphne를 다시 구성합니다.

reconstruct -f -r user/daphne

모든 메일함을 수정하지 않고 검사하려면 다음과 같이 -n 옵션을 사용합니다.

reconstruct -r -n

메일함 검사 및 복구

메일함 데이터베이스의 고급 일관성 검사와 복구를 수행하려면 다음 명령을 사용합니다.

reconstruct -m

기본 분할 영역의 일관성 검사와 복구를 수행하려면 다음 명령을 사용합니다.

reconstruct -p primary -m

reconstruct를 -p 및 -m 플래그와 함께 실행하면 lright.db가 수정되지 않습니다. 이는 lright.db를 수정하려면 메일 저장소의 모든 사용자에 대한 ACL을 스캔해야 하기 때문입니다. 모든 분할 영역에 대해 이 작업을 수행하는 것은 그리 효율적이지 않습니다. lright.db를 수정하려면 reconstruct -l을 실행합니다.

john이라는 개별 사용자의 메일함에 대한 일관성 검사와 복구를 수행하려면 다음 명령을 사용합니다.

reconstruct -p primary -u john -m

다음 경우에 -m 옵션을 사용해야 합니다.

• 하나 이상의 디렉토리가 저장소 스풀 영역에서 제거되어 메일함 데이터베이스 항목 또한 제거해야 하는 경우

• 하나 이상의 디렉토리가 저장소 스풀 영역에서 복원되어 메일함 데이터베이스 항목을 또한 추가해야 하는 경우

• stored -d 옵션으로 데이터베이스의 일관성을 유지할 수 없는 경우

  stored -d 옵션으로 데이터베이스의 일관성을 유지할 수 없는 경우에는 다음 단계를 나열된 순서대로 수행합니다.

  • 모든 서버를 종료합니다.

  • store_root/mboxlist의 모든 파일을 제거합니다.

  • 서버 프로세스를 다시 시작합니다.

  • reconstruct -m을 실행하여 스풀 영역 내용에서 새 메일함 데이터베이스를 작성합니다.

reconstruct 성능

reconstruct가 작업을 수행하는 데 걸리는 시간은 다음 요소에 따라 달라집니다.

• 수행하는 작업의 종류 및 선택한 옵션

• 디스크 성능

• reconstruct -m 실행 시의 폴더 수

• reconstruct -r 실행 시의 메일 수

• 메일 저장소의 전체 크기

• 시스템이 실행 중인 다른 프로세스 및 시스템 사용량

• 진행 중인 POP, IMAP, HTTP 또는 SMTP 활동이 있는지 여부

reconstruct -r 옵션은 초기 일관성 검사를 수행합니다. 이 검사는 다시 작성해야 하는 폴더 수에 따라 reconstruct 성능을 향상시킵니다.

약 2400명의 사용자와 85GB의 메일 저장소가 있으며 서버에 동시 POP, IMAP 또는 SMTP 활동이 있는 시스템에서 다음 성능이 확인되었습니다.

• reconstruct -m은 약 1시간이 걸렸습니다.

• reconstruct -r -f는 약 18시간이 걸렸습니다.

진행 중인 POP, IMAP, HTTP 또는 SMTP 활동을 서버에서 수행하지 않을 경우 reconstruct 작업에는 훨씬 더 적은 시간이 소요될 수 있습니다.

일반 문제 및 해결 방법

이 절에서는 다음과 같은 일반적인 메일 저장소 문제와 해결 방법에 대해 설명합니다.

• 메일 페이지를 로드하지 않는 Messenger Express 또는 Communications Express

• 와일드카드 패턴을 사용하는 명령이 작동하지 않음

• 알 수 없거나 잘못된 분할 영역

• 사용자 메일함 디렉토리 문제

메일 페이지를 로드하지 않는 Messenger Express 또는 Communications Express

사용자가 Messenger Express 페이지 또는 Communications Express 메일 페이지를 로드할 수 없는 경우 압축 후에 데이터가 손상되었을 수 있습니다. 이 문제는 시스템에서 오래된 프록시 서버를 배포한 경우에 종종 발생할 수 있습니다. 이 문제를 해결하려면 local.service.http.gzip.static 및 local.service.http.gzip.dynamic을 0으로 설정하여 데이터 압축을 비활성화해 보십시오. 문제가 해결되면 프록시 서버를 업데이트할 수 있습니다.

와일드카드 패턴을 사용하는 명령이 작동하지 않음

UNIX 쉘의 경우 일부는 와일드카드 매개 변수에 따옴표가 필요하지만 일부는 그렇지 않습니다. 예를 들어, C 쉘은 와일드카드(*, ?)를 파일로 포함하는 인수 확장을 시도하며 일치하는 항목이 없으면 실패합니다. 이러한 패턴 일치 인수를 mboxutil과 같은 명령에 전달하려면 따옴표로 묶어야 할 수 있습니다.

예를 들면 다음과 같습니다.

mboxutil -l -p user/usr44*

Bourne 쉘에서 작동하지만 tsch 및 C 쉘에서는 실패합니다. 이러한 쉘에는 다음이 필요합니다.

mboxutil -l -p "user/usr44*"

와일드카드 패턴을 사용하는 명령이 작동하지 않을 경우 해당 쉘의 와일드카드를 따옴표로 묶어야 하는지 여부를 확인합니다.

알 수 없거나 잘못된 분할 영역

메일함을 방금 만든 새 분할 영역으로 이동했거나 Messaging Server를 갱신 또는 다시 시작하지 않은 경우 Messenger Express에서 "Unknown/invalid partition"이라는 메시지가 표시될 수 있습니다. 이 문제는 새 분할 영역에서만 발생합니다. 이제 추가 사용자 메일함을 이 새 분할 영역에 추가할 경우 Messaging Server를 갱신 또는 다시 시작할 필요가 없습니다.

사용자 메일함 디렉토리 문제

메일 저장소 손상이 몇몇의 사용자로 제한되고 시스템에 대한 전역 손상이 없을 경우 사용자 메일함 문제가 발생합니다. 다음 지침은 사용자 메일함 디렉토리 문제를 식별, 분석 및 해결하기 위한 프로세스를 제시합니다.

1. 로그 파일, 오류 메시지 또는 관찰된 모든 비정상적인 동작을 검토합니다.

2. 정보와 기록을 계속 디버깅하려면 전체 store_root/mboxlist/ 사용자 디렉토리를 메일 저장소 외부의 다른 위치로 복사합니다.

3. 문제를 일으키는 사용자 폴더를 찾으려면 reconstruct -r -n 명령을 실행합니다. reconstruct를 사용하여 폴더를 찾을 수 없는 경우 folder.db에 폴더가 존재할 수 있습니다.

   reconstruct -r -n 명령을 사용하여 폴더를 찾을 수 없는 경우 hashdir 명령을 사용하여 위치를 확인합니다. hashdir에 대한 자세한 내용은 hashdir 유틸리티와 Sun Java System Messaging Server 6 2005Q4 Administration Reference의 Messaging Server Command-line Utilities 장에서 hashdir 유틸리티를 참조하십시오.

4. 폴더를 찾은 후에는 파일과 권한을 검사하고 적절한 파일 크기를 확인합니다.

5. reconstruct -r(-n 옵션 없이)을 사용하여 메일함을 다시 작성합니다.

6. 사용자가 관찰한 문제를 reconstruct에서 감지하지 않을 경우 reconstruct -r -f 명령을 실행하여 메일 폴더를 다시 구성할 수 있습니다.

7. 폴더가 mboxlist 디렉토리(store_root/mboxlist)에 존재하지 않지만 partition 디렉토리(store_root/partition)에 존재할 경우 전역 불일치가 존재할 수 있습니다. 이 경우 reconstruct -m 명령을 실행해야 합니다.

8. 이전 단계들로 문제가 해결되지 않을 경우 store.idx 파일을 제거하고 reconstruct 명령을 다시 실행할 수 있습니다.

   ---

   주의 –

   reconstruct 명령으로 검색할 수 없는 파일에 문제가 있다고 확신하는 경우에만 store.idx 파일을 제거해야 합니다.

   ---

9. 문제가 특정 메일로 한정된 경우 해당 메일 파일을 메일 저장소 외부의 다른 위치로 복사하고 mailbox/ 디렉토리에서 reconstruct -r 명령을 실행해야 합니다.

10. 폴더가 디스크(store_root/partition/ 디렉토리)에 존재하지만 데이터베이스(store_root/mboxlist/ 디렉토리)에는 확실하게 없을 경우 reconstruct -m 명령을 실행하여 메일 저장소 일관성을 확인합니다.

reconstruct 명령에 대한 자세한 내용은 메일함 및 메일함 데이터베이스 복구를 참조하십시오.

저장소 데몬이 시작되지 않음

stored가 시작되지 않고 다음 오류 메시지가 반환됩니다.

# msg_svr_base/sbin/start-msg

msg_svr_base: Starting STORE daemon ...Fatal error: Cannot
find group in name service

이 오류 메시지는 local.servergid에 구성된 UNIX 그룹을 찾을 수 없다는 것을 나타냅니다. Stored 및 다른 유틸리티에서는 해당 gid가 이 그룹으로 설정되어야 합니다. 경우에 따라 실수로 local.servergid에 의해 정의된 그룹이 삭제될 수 있습니다. 이런 경우에는 삭제된 그룹을 만들고 inetuser를 그룹에 추가한 다음 instance_root와 해당 파일의 소유권을 inetuser 및 해당 그룹으로 변경합니다.