CM 7.11.3 재설치 중 %prein 스크립틀릿이 Java 를 찾지 못해 실패하고, 이후 서버가 기동 직후 죽으며, 로그인 뒤 화면이 넘어가지 않던 사례다. 원인은 세 가지가 겹쳐 있었다. JAVA_HOME 과 alternatives·PATH 의 Java 가 서로 달랐고, 로그 디렉터리 소유권이 root 로 바뀌어 있었으며, 브라우저 캐시가 옛 정적 리소스를 물고 있었다.
alternatives --config java 에는 OpenJDK 8 만 등록돼 있는데 JAVA_HOME 은 JDK 11 을 가리키고, 어떤 호스트는 ~/.bashrc 에 예전 CM 마법사가 설치한 /usr/java/jdk1.8u372-b07-cloudera/bin 이 PATH 앞에 박혀 있었다. CDP 7.1.9(CM 7.11.3) 는 JDK 8/11/17 을 모두 지원하므로 버전이 아니라 탐지가 꼬인 것이다.
type -a java
echo $PATH
grep -rn 'JAVA_HOME\|jdk1.8u\|/usr/java' /etc/profile.d/*.sh /etc/profile /etc/bashrc ~/.bashrc ~/.bash_profile
찾은 줄을 지운 뒤 현재 셸은 이미 오염된 PATH 를 메모리에 갖고 있으므로 source 로는 지워지지 않는다. exec bash -l 로 새 세션을 열거나 PATH 를 직접 재조립한다.
export PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/root/bin
hash -r
which java; java -version
영구 설정은 /etc/profile.d 에 두되, 알파벳순으로 나중에 실행돼 다른 스크립트에 덮이지 않도록 이름을 zzz-java.sh 로 한다. JDK 레이아웃(RPM 은 jre/bin/java, tar 설치는 bin/java) 이 호스트마다 달라 dirname 3단계 트릭은 쓰지 않는다.
cat > /etc/profile.d/zzz-java.sh << 'EOF'
export JAVA_HOME=/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.402.b06-2.el8.x86_64
export PATH=$JAVA_HOME/bin:$PATH
EOF
chmod 644 /etc/profile.d/zzz-java.sh
systemd 가 띄우는 서비스는 로그인 셸의 환경을 물려받지 않으므로 CM 서버가 쓸 Java 는 /etc/default/cloudera-scm-server 에 지정한다.
echo 'export JAVA_HOME=/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.402.b06-2.el8.x86_64' > /etc/default/cloudera-scm-server
모든 클러스터 호스트에 동일 벤더·버전의 JDK 를 두는 것이 Cloudera 요구사항이다. 한 호스트만 Temurin 인 경우 RPM 판으로 통일한다.
java.io.FileNotFoundException: /var/log/cloudera-scm-server/cmf-server-nio.log (Permission denied)
Caused by: java.lang.NullPointerException at ...LogUtil.getServerLogfile
root 로 vi 로 로그 파일을 열어 저장하면서 소유자가 바뀐 것이 원인이었다. CM 서버는 cloudera-scm 계정으로 실행된다. JVM 이 뜨기 전 셸 단계 실패는 .log 가 아니라 .out 에만 찍히므로 cloudera-scm-server.out 도 본다.
chown -R cloudera-scm:cloudera-scm /var/log/cloudera-scm-server /var/lib/cloudera-scm-server
systemctl restart cloudera-scm-server
journalctl -u cloudera-scm-server -n 100 --no-pager
tail -50 /var/log/cloudera-scm-server/cloudera-scm-server.out
relation "cm_version" does not exist 가 함께 나오면 db.properties 의 DB 가 실제 스키마가 있는 DB 인지 확인한다.
서버가 여러 번 재시작되며 정적 리소스 버전이 바뀌어 브라우저 캐시와 어긋난 것이다. 시크릿 창에서 정상이면 확정이며, 해당 사이트의 캐시·쿠키를 지우면 된다. 재설치 뒤 기본 admin 비밀번호는 즉시 변경한다.