문제해결

본 장에서는 잘못된 설치용 속성 파일 작성으로 인해 발생할 수 있는 에러 중 자주 발생하는 유형을 소개하고, 유형별 해결방법을 기술한다.

1. 개요

Base 설치 과정에서 발생하는 에러는 다음의 3가지 경로를 통해 발견할 수 있다.

${OPENFRAME_HOME}/UninstallerData/log/install_base.log 파일을 텍스트 에디터로 직접 열어 확인한다.
Base를 설치한 후 수동으로 스크립트를 실행할 때 기록된 에러 로그를 확인한다.
OpenFrame의 기동을 확인할 때 나타나는 서버 상태 로그 정보를 확인한다.

설치용 속성 파일 작성에 대한 자세한 내용은 설치용 속성 파일 작성을 참고한다.
에러 코드에 대한 자세한 내용은 OpenFrame Base "에러 메시지 참조 안내서"를 참고한다.

2. 에러 유형 및 해결방법

다음은 잘못된 설치용 속성 파일 또는 라이선스 파일로 인해 Base 설치 중 빈번히 발생하는 에러 및 유형별 해결방법에 대해 소개한다.

2.1. 라이선스 파일

라이선스 파일이 존재하지 않거나 손상된 경우 또는 라이선스 기간이 만료된 경우 다음과 같은 에러가 발생한다.

유형
- Tmax 라이선스 파일이 없는 경우
  
  boot.sh 스크립트 파일을 실행하면 다음과 같은 에러가 발생한다.
  (E) CFL2141 failed to read license file : /home/oframe/OpenFrame/core/license/license.dat [COM0900]
- Tmax 라이선스 파일 기간이 만료된 경우
  
  boot.sh 스크립트 파일을 실행하면 다음과 같은 에러가 발생한다.
  (E) CFL2145 License is expired : [COM0906]
- Tmax 라이선스 파일이 손상된 경우
  
  boot.sh 스크립트 파일을 실행하면 다음과 같은 에러가 발생한다.
  (E) CFL2142 Corrupt license file : /home/oframe/OpenFrame/core/license/license.dat [COM0902]
- Base 모듈별 라이선스가 없거나 잘못된 경우
  
  Base를 기동할 때 해당 모듈 서버가 올바르게 실행되지 않으며 tmadmin을 통해 서버 상태를 확인할 때 NRDY가 표시된다.
  
  서버가 올바르게 실행되고 있는지 확인하기 위해 tmadmin을 실행한 후 si 명령어를 실행한다. 자세한 내용은 기동 확인의 5번을 참고한다.
해결방법

라이선스 관련 문의는 TmaxSoft의 기술 지원에 문의한다.

2.2. 공유 메모리

다음은 공유 메모리 키 값이 중복될 경우의 설명이다.

유형 1)
- 에러 코드 : CFL0096
  
  설치용 속성 파일에 등록한 공유 메모리 키 값이 다른 사용자 또는 프로그램에 의해 사용 중인 키 값과 중복될 경우 OpenFrame 서버는 기동되지 않는다. 이 경우 ${OPENFRAME_HOME}/UninstallerData/log 디렉터리의 install_base.log 파일을 보면 아래와 같은 에러를 확인할 수 있다.
  (E) CFL0096 shared memory : different owner 1010 [COM3517]: File exists (E) CFL0096 shared memory : different owner 1010 [COM3517]: File exists (E) CFL0096 shared memory : different owner 1010 [COM3517]: File exists (E) CFL0096 shared memory : different owner 1010 [COM3517]: File exists
- 해결방법
  
  설치용 속성 파일에 등록한 공유 메모리 키 값을 수정하고 다시 설치를 시도하거나, ${OPENFRAME_HOME}/config 디렉터리 또는 ${OPENFRAME_HOME}/core/config 디렉터리에 위치한 oframe.m 파일에서 해당 값을 찾아 수정한 다음 재실행한다.
유형 2)
- 에러 코드 : ALC0001E
  
  Base 제품을 설치한 후 tmboot할 때 서버가 정상적으로 기동되지 않고 아래와 같은 에러가 발생할 수 있다.
  “[ALC0010E] shared memory size mismatch - shmkey=0x9471,segsz=1673932”
- 해결방법
  
  설치용 속성 파일에 등록한 공유 메모리 키 값을 수정하고 다시 설치를 시도하거나, ${OPENFRAME_HOME}/core/config 디렉터리에 위치한 TMAX config 에서 해당 값을 찾아 수정한 다음 수동으로 반영시키면 된다.
  
  아래 예제는 TMAX 공유 메모리 키를 수동으로 반영시키는 방법이다.
  # vi $OPENFRAME_HOME/core/config/oframe.m *DOMAIN domain SHMKEY = 38001 # $TMAXDIR/bin/pfmtcacheadmin -d # $TMAXDIR/bin/pfmtcacheadmin -c # vi $OPENFRAME_HOME/core/config/pfmtcache.cfg * the configuration file of TCACHE SHMKEY=39082 # $TMAXDIR/bin/cfl -i $TMAXDIR/config/oframe.m

2.3. 데이터베이스

다음은 OpenFrame 데이터베이스 접속 정보 설정이 잘못된 경우 발생하는 경우의 설명이다.

유형

설치용 속성 파일을 작성할 때 저장 장치 환경설정에서 데이터베이스 접속 정보를 잘못 입력했을 경우 OpenFrame 서버는 기동되지 않는다.

${OPENFRAME_HOME}/UninstallerData/log 디렉터리의 install_base.log 파일을 보면 아래와 같은 에러를 확인 할 수 있다.
```
ofcom_odbc: SQLConnect failed. State: 08001, Native Error: -17001, Message: [unixODBC] Login failed: invalid user name or password.
```
해결방법

설치용 속성 파일에서 저장 장치 환경설정을 올바르게 수정하고 다시 설치를 실행한다.

2.4. 보안 모듈

다음은 보안 모듈에서 라이브러리 접근을 차단하는 경우의 설명이다.

유형

Linux의 보안 모듈인 SELinux를 사용하는 일부 Linux 시스템의 경우 SELinux의 보안 정책상 일부 라이브러리의 접근을 차단하여 다음과 같은 에러가 발생할 수 있다.
```
“cannot restore segment prot after reloc: Permission denied”
```
해결방법
- Permission denied가 발생하는 라이브러리를 대상으로 다음과 같이 chcon을 실행한다. 라이브러리에 따라서는 슈퍼 유저 권한이 필요할 수도 있다.
  chcon -t texrel_shlib_t [원하는 so 라이브러리]
- 슈퍼 유저로 접속한 다음 아래와 같이 /etc/sysconfig/selinux 파일을 수정하여 SELInux를 비활성화한다. 단, 이 방법은 보안 정책을 약화시킬 수 있으므로 권장하지는 않는다.
  SELINUX=disabled

2.5. UNIX ODBC

다음은 UNIX ODBC 관련 설정이 잘못된 경우 발생하는 경우의 설명이다.

유형 1)

Base 제품을 설치한 후 ofversion 등의 실행 프로그램을 수행할 때 라이브러리(libodbc.so)를 찾지 못하고 아래와 같은 에러가 발생할 수 있다.

$ ofversion
ofversion: error while loading shared libraries: libodbc.so.1: cannot open shared object file: No such file or directory

$ ldd ofversion
        linux-vdso.so.1 =>  (0x00007fff02fc1000)
        libofcom.so => /home/oframe4/OpenFrame/lib/libofcom.so (0x00007fb978d44000)
        libc.so.6 => /lib64/libc.so.6 (0x0000003ab5400000)
        /lib64/ld-linux-x86-64.so.2 (0x0000003ab5000000)
        libodbc.so.1 => not found

해결방법

UNIX ODBC 2.3.1 version이 Released되면서 library version이 1에서 2로 바뀌었다(libodbc.so.1에서 libodbc.so.2로 변경). 설치 후 libodbc.so(libodbc.so.1)를 찾지 못 한다면 심볼링 링크를 생성한다.

$ ll /usr/lib64/libodbc.so*
lrwxrwxrwx. 1 root root     16 Jan 12  2015 /usr/lib64/libodbc.so -> libodbc.so.2.0.0
lrwxrwxrwx. 1 root root     16 Jan 12  2015 /usr/lib64/libodbc.so.2 -> libodbc.so.2.0.0
-rwxr-xr-x. 1 root root 420200 Jul 10  2014 /usr/lib64/libodbc.so.2.0.0

$ ln -sf /usr/lib64/libodbc.so.2.0.0 /usr/lib64/libodbc.so.1

유형 2)

isql을 사용해서 UNIX ODBC로 DB에 접속할 때 UNIX ODBC Driver Manager에서 에러가 발생할 수 있다.

$ isql oframe tibero tmax
[ISQL]ERROR: Could not SQLConnect

UNIX ODBC 설정 파일 odbcinst.ini에서 [ODBC] 절의 TraceFile에 기술한 로그 파일을 읽어보면 아래와 같은 에러(Error: IM002)을 확인 할 수 있다.

[ODBC][64494][1136898658.284331][SQLConnect.c][3727]
                 Entry:
                          Connection = 0x1c51080
                          Server Name = [oframe][length = 7 (SQL_NTS)]
                          User Name = [tibero][length = 6 (SQL_NTS)]
                          Authentication = [****][length = 4 (SQL_NTS)]
[ODBC][64494][1136898658.284619][SQLConnect.c][3935]Error: IM002

해결방법

UNIX ODBC 설정 파일 odbc.ini에서 섹션 이름과 DSN 이름을 확인하고 동일하게 수정한다.

2.6. 엔진 기동할 때 CLH9990 에러 발생

다음은 시스템에서 허용하는 FD 최댓값이 Tmax에서 사용하는 FD 값보다 작아 CLH9990 에러가 발생하는 경우에 대한 설명이다.

유형

Base 제품을 설치한 후 tmboot할 때 CLH 서버가 정상적으로 기동되지 않고 clh 에러 로그에 아래와 같은 에러가 발생할 수 있다.
```
“(F) CLH9990 Current Tmax configuration contains more servers
        or nodes than current system can support.”
```
해결방법

UNIX 시스템에서 현재 허용하는 nofile에 대한 hard limit, soft limit 값을 수정한다. 아래의 예제는 Linux 시스템에서 해당 값을 8192으로 수정하는 방법이다.
```
# vi /etc/security/limits.conf

*                hard   nofile           8192
*                soft   nofile           8192
```
각 OS별로 해당 값을 변경하는 방법이 다를 수 있으므로 각 OS 벤더사에서 제공하는 매뉴얼을 참고하거나 엔지니어의 도움을 받아 처리한다.