Sun Java System Messaging Server 6.3 관리 설명서

20.14.4 일반 문제 및 해결 방법

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

20.14.4.1 Linux - Messaging Server 패치 120230-08 IMAP, POP 및 HTTP 서버가 프로세스 당 세션 초과 때문에 시작되지 않음

이 패치를 설치한 후 Messaging Server를 설치하려 하면 IMAP, POP 및 HTTP 서버가 시작되지 않고 다음 예와 같은 오류 로그를 보낼 수 있습니다.


http server - log:
[29/May/2006:17:44:37 +051800] usg197 httpd[6751]: General Critical: Not enough file 
descriptors to support 6000 sessions per process; Recommend ulimit -n 12851 or 87 
sessions per process.

pop server - log:
[29/May/2006:17:44:37 +051800] usg197 popd[6749]: General Critical: Not enough file 
descriptors to support 600 sessions per process; Recommend ulimit -n 2651 or 58 
sessions per process.

Once these values setting in /opt/sun/messaging/sbin/configutil then imap server 
failed to start

imap server - log: 
[29/May/2006:17:44:37 +051800] usg197 imapd[6747]: General Critical: Not enough 
file descriptors to support 4000 sessions per process; Recommend ulimit -n 12851 
or 58 sessions per process.

세 서버 세션 모두에 적절한 수의 파일 설명자를 설정합니다. 다음과 비슷한 행을 /etc/sysctl.conf에 추가하고 sysctl -p를 사용하여 파일을 다시 읽으면 추가 파일 설명자를 사용할 수 있습니다.


fs.file-max = 65536 

또한 다음과 같은 행을 /etc/security/limits.conf에 추가해야 합니다.


*   soft  nofile  65536  
*   hard  nofile  65536

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

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

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

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

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

mboxutil -l -p user/usr44*

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

mboxutil -l -p "user/usr44*"

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

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

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

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

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

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

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

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

    reconstruct -r -n 명령을 사용하여 폴더를 찾을 수 없는 경우 hashdir 명령을 사용하여 위치를 확인합니다. hashdir에 대한 자세한 내용은 Sun Java System Messaging Server 6.3 Administration Reference의 Messaging Server Command-line Utilities 장에 있는 20.11.2.3 hashdir 유틸리티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 명령에 대한 자세한 내용은 20.14.3 메일함 및 메일함 데이터베이스 복구를 참조하십시오.

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

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에 의해 정의된 그룹이 삭제될 수 있습니다. 이런 경우에는 삭제된 그룹을 만들고 mailsrv를 그룹에 추가한 다음 instance_root와 해당 파일의 소유권을 mailsrv 및 해당 그룹으로 변경합니다.

20.14.4.7 메일함 오버플로 때문에 사용자 메일이 전달되지 않음

메시지 저장소의 store.idx 파일에는 2GB의 엄격한 제한이 적용됩니다. 이는 단일 메일함(폴더)에 약 100만 개의 메시지가 들어가는 정도에 해당됩니다. store.idx 파일이 2GB를 초과하려 할 정도로 메일함이 커지면 사용자는 새 전자 메일을 받지 못하게 됩니다. 또한 imapd, popd, mshttpd와 같이 해당 메일함을 처리하는 다른 프로세스의 성능도 저하될 수 있습니다.

이 문제가 발생하면 mail.log_current에 다음과 같은 오류가 표시됩니다.

05-Oct-2005 16:09:09.63 ims-ms Q 7 ...System I/O error.Administrator, check server log for details.System I/O error.

그 외에도 MTA 로그 파일에는 다음과 같은 오류가 표시됩니다.

[05/Oct/2005:16:09:09 +0900] jmail ims_master[20745]:Store Error:Unable to append cache for user/admin:File too large

사용자의 메시지 저장소 디렉토리에 있는 파일을 조회하거나 imta 로그 파일에서 자세한 메시지를 확인하면 이 문제가 발생한 것을 확실히 알 수 있습니다.

즉시 필요한 조치는 파일의 크기를 줄이는 것입니다. 일부 메일을 삭제하거나 다른 메일함으로 옮기십시오. mboxutil -r을 사용하여 폴더 이름을 변경할 수도 있고 mboxutil -d를 사용하여 폴더를 삭제할 수도 있습니다( 20.11.2.1 mboxutil 유틸리티 참조).

장기적으로는 사용자에게 메일함 크기 제한에 대해 알리거나, 에이징 정책( 20.9 자동 메시지 제거(만료 및 제거) 기능 설정 방법 참조)과 할당량 정책( 20.8 메시지 저장소 할당량 정보 참조)을 구현하거나, local.store.maxmessages를 설정하여 메일함 제한을 설정하거나(Sun Java System Messaging Server 6.3 Administration Referenceconfigutil Parameters 참조), 아카이브 시스템을 설정하거나, 메일함 크기를 제어 범위 내로 유지하기 위한 조치를 취해야 합니다.