I currently have CDH 5 installed on CentOS 6.5 with java jdk1.7 and I am trying to get CDH to use jdk1.8.
I do know that Java 1.8 is not a recommended version of CDH, but it is only a test cluster, so it isn't a big deal.
I have installed both Java 1.7 and Java 1.8 from Oracle's website using the RPM installation, so both versions of Java are currently under /usr/java. Using ls -ld my Java directory looks like:
/usr/java/default -> /usr/java/latest
/usr/java/jdk1.7.0_75
/usr/java/jdk1.8.0_31
/usr/java/latest -> /usr/java/jdk1.8.0_31
I also have script set up in /etc/profile.d to set $JAVA_HOME to /usr/java/default. The contents of my profile.d script:
export JAVA_HOME=/usr/java/default
export PATH=${JAVA_HOME}/bin:${PATH}
So when felt that I have this right, I run:
$ which java
/usr/java/default/bin/java
Telling me that it is pointing to the version of Java symlinked in default. And to determine which version of java is running, I run:
$ java -version
java version "1.8.0_31"
Java(TM) SE Runtime Environment (build 1.8.0_31-b13)
Java HotSpot(TM) 64-Bit Server VM (build 25.31-b07, mixed mode)
And I can see that I have Java 1.8 currently running.
Everything seems great, except when I try to start a Hadoop service. The easiest to start is ZooKeeper, because it only has one service. HDFS has multiple servers so it is more work that to just start and stop ZooKeeper.
Starting ZooKeeper is done with the following command:
$ sudo service zookeeper-server start
Then to check which version of java it is running, I search the running processes list for java:
$ ps -ef | grep java
495 7170 1 7 12:27 ? 00:00:00 /usr/java/jdk1.7.0_75/bin/java -Dzookeeper.datadir.autocreate=false -Dzookeeper.log.dir=/var/log/zookeeper -Dzookeeper.root.logger=INFO,ROLLINGFILE -cp /usr/lib/zookeeper/bin/../build/classes:/usr/lib/zookeeper/bin/../build/lib/*.jar:/usr/lib/zookeeper/bin/../lib/slf4j-log4j12.jar:/usr/lib/zookeeper/bin/../lib/slf4j-log4j12-1.7.5.jar:/usr/lib/zookeeper/bin/../lib/slf4j-api-1.7.5.jar:/usr/lib/zookeeper/bin/../lib/netty-3.2.2.Final.jar:/usr/lib/zookeeper/bin/../lib/log4j-1.2.16.jar:/usr/lib/zookeeper/bin/../lib/jline-0.9.94.jar:/usr/lib/zookeeper/bin/../zookeeper-3.4.5-cdh5.3.0.jar:/usr/lib/zookeeper/bin/../src/java/lib/*.jar:/etc/zookeeper/conf::/etc/zookeeper/conf:/usr/lib/zookeeper/*:/usr/lib/zookeeper/lib/* -Dzookeeper.log.threshold=INFO -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.local.only=false org.apache.zookeeper.server.quorum.QuorumPeerMain /etc/zookeeper/conf/zoo.cfg
I know that runs off the screen, bu the important part is that Zookeeper is being started by /usr/java/jdk1.7.0_75/bin/java.
To fix this, I have tried a few things:
Looking at the conf files for Hadoop and ZooKeeper under /etc/hadoop/conf and /etc/zookeeper/conf, respectively.
I found nothing setting JAVA_HOME.
Looking at the /usr/bin/zookeeper script to see if JAVA_HOME was set elsewhere,
I did find the script /usr/lib/bigtop-utils/bigtop-detect-javahome has the ability to set JAVA_HOME, but my profile.d script overrides that.
Manually moving /usr/java/jdk1.7 to /tmp.
Sadly, this is the only thing that works. When I move the jdk1.7 dir to another directory, and start ZooKeeper, it will use Java 1.8. Moving the jdk1.7 dir back, reverts to ZooKeeper using Java 1.7.
Has anyone dealt with this problem and does anyone know how to deal with this? I feel that I have Java set up correctly, but something is telling ZooKeeper/Hadoop to use an old version of Java?
I came here because I was looking for ways to upgrade JDK from 1.7 to 1.8 on the latest Coudera QuickStart VM 5.8 (can't believe they still ship it with JDK1.7 by default!). The hints and suggestions in the above answers helped tremendously - but since they were not listing complete steps to achieve the upgrade - I thought I would add that to help others like me.
So, here is a complete set of steps to upgrade Cloudera QuickStart VM from JDK1.7 to 1.8:
check your current JDK version - out-of-the-box it is:
[cloudera#quickstart ~]$ java -version
java version "1.7.0_67"
Java(TM) SE Runtime Environment (build 1.7.0_67-b01)
Java HotSpot(TM) 64-Bit Server VM (build 24.65-b04, mixed mode)
download desired version of JDK1.8.xx - in my case: jdk-8u111-linux-x64.tar.gz
as user 'cloudera':
untar and move the resulting jdk1.8.0_111 dir to the /usr/java dir:
tar xzf jdk-8u111-linux-x64.tar.gz
sudo mv -f jdk1.8.0_111 /usr/java
shutdown all Hadoop services:
$ for x in `cd /etc/init.d ; ls hadoop-*` ; do sudo service $x stop ; done
update bigtop-utils file - set JAVA_HOME to your new JDK:
sudo vi /etc/default/bigtop-utils
updated lines:
# Override JAVA_HOME detection for all bigtop packages
export JAVA_HOME=/usr/java/jdk1.8.0_111
update 'cloudera' user's .bash_profile - export JAVA_HOME and add update PATH:
export JAVA_HOME=/usr/java/jdk1.8.0_111
PATH=$JAVA_HOME/bin:$PATH:$HOME/bin
export PATH
restart your VM
check Java version - should be the 1.8 one now:
[cloudera#quickstart ~]$ java -version
java version "1.8.0_111"
Java(TM) SE Runtime Environment (build 1.8.0_111-b14)
Java HotSpot(TM) 64-Bit Server VM (build 25.111-b14, mixed mode)
By the way, I did not setup the /usr/java/default with the 'latest' sym link as #milk3422 did, for the sake of simplicity, but it would have worked just as well.
thanks!
I hate to answer my own questions, but here is the answer:
The wrong version of $JAVA_HOME is getting set for 2 reasons:
Using the command service removes most environmental variables. From man service:
service runs a System V init script in as predictable environment as
possible, removing most environment variables and with current work-
ing directory set to /.
The /usr/lib/bigtop-utils/bigtop-detect-javahome script has the ability to be configured with the environment variable BIGTOP_JAVA_MAJOR to manually set which version of Java to use. I tried setting this as an environment variable, but service removes it :(. It is also important to note that this script will find all versions of java installed, but the order of preference is Java 6, Java 7, Java 8, Open Java. So if you have Java 6, and 8 installed, it will prefer 6 over 8.
In short, to fix my problem, I added the following to the top of /usr/lib/bigtop-utils/bigtop-detect-javahome:
BIGTOP_JAVA_MAJOR=8
You can also set JAVA_HOME in this file to specify a specific version or path.
I had the same problem. I set
JAVA_HOME=... below the file /usr/lib/bigtop-utils/bigtop-detect-javahome
to override the default detect value. That works great!
Java is configurable in the web UI. Open Cloudera Manger --> Hosts --> Configurations --> Advanced, then set the JAVA HOME. This overrides the CDH's Java detection mechanism.
Related
I have trouble when trying to open my jar files with the following command:
java -jar software.jar
They load until a certain point and then nothing happens.
I deinstalled default-jdk and OpenJDK with synaptic and re-installed it with apt-get, but nothing changed. I had a similar problem one month ago and solved it (apparently only temporarly) by deleting the package gcj-5-jre-lib (5.4.0-6ubuntu1~16.04.4) (Java runtime library for use with gcj (jar files))
The following outputs will help:
java -version
openjdk version "1.8.0_131"
OpenJDK Runtime Environment (build 1.8.0_131-8u131-b11-2ubuntu1.16.04.3-b11)
OpenJDK 64-Bit Server VM (build 25.131-b11, mixed mode)
javac -version
1.8.0_131
My variables $JAVA_HOME and $JRE_HOME were correctly added to my $PATH.
I'm on Ubuntu 16.04
EDIT
Here is an example of what I get when I try to start PhyDE.jar
java -jar PhyDE.jar
Welcome to PhyDE 0.9971!
Reading preferences.
Creating PhyDE-Application window
Checking for updates...
You are using the latest version of PhyDE
Done with checking for updates
When checking the core use with the command top I see that the process is active, but the user interface does not open as it usually does. I am located in the folder where the jar file is, and same happens with other jar files.
I am trying to upgrade to: Java 8 Update 66, from Java 6, on my Mac running Mac OS X 10.10.5. I downloaded the Java Update .dmg file: re-8u66-macosx-x64.dmg. When I run the installer I get the message it installed properly. When I confirmed the install via the FireFox Browser at this URL:
https://java.com/en/download/installed.jsp
It reports:
Congratulations!
You have the recommended Java installed (Version 8 Update 66).
However, If I open a terminal window and enter: java -version
It reports:
java version "1.6.0_65"
Java(TM) SE Runtime Environment (build 1.6.0_65-b14-466.1-11M4716)
Java HotSpot(TM) 64-Bit Server VM (build 20.65-b04-466.1, mixed mode)
Can someone please explain what is going on here? Do I need to update a link somewhere?
Thanks.
Please check your PATH variable, and make sure that the java directories in the path match the directories in your computer. It should be the bin folder of the JAVA_HOME environment directory. Also check that JAVA_HOME environment variable is set to the jdk folder of your java installation.
There's two option based on my experience to fix this issue, fisrt uninstalled the java on your computer and reinstalled using the latest version.
Second, run a different version of Java, either specify the full path, or use the java_home tool:
List your installed java version:
$ /usr/libexec/java_home -V
In this case you are using java 8 so you can run command
$ /usr/libexec/java_home -v 1.8 --exec javac -version
If you want to make easy to switch your java version you can create alias in ~/.bashrc
alias java6="export JAVA_HOME=$(/usr/libexec/java_home -v 1.6);echo 'using Java 6'"
alias java8="export JAVA_HOME=$(/usr/libexec/java_home -v 1.8);echo 'using Java 8'"
Hope it help
$ cassandra
Cassandra 2.0 and later require Java 7 or later.
OK, what's going on in that part of the init script?
java_ver_output=`"${JAVA:-java}" -version 2>&1`
jvmver=`echo "$java_ver_output" | awk -F'"' 'NR==1 {print $2}'`
JVM_VERSION=${jvmver%_*}
JVM_PATCH_VERSION=${jvmver#*_}
if [ "$JVM_VERSION" \< "1.7" ] ; then
echo "Cassandra 2.0 and later require Java 7 or later."
exit 1;
fi
Hmm, if I get the version at the command line:
$ java_ver_output=`"${JAVA:-java}" -version 2>&1`
$ echo $java_ver_output
java version "1.7.0_55" Java(TM) SE Runtime Environment (build 1.7.0_55-b13) Java HotSpot(TM) 64-Bit Server VM (build 24.55-b03, mixed mode)
$ JVM_VERSION=${jvmver%_*}
$ echo $JVM_VERSION
1.7.0
If I run which java:
$ which java
/usr/bin/java
If I put that line in the script:
/usr/bin/java
The frustrating part here is that I've got this running in the past but since I bounced the server I can't get cassandra to start.
So I'm confused here, how is Cassandra confused about what version of Java I'm running? How do I get cassandra running? Is 1.7.0_55 not Java 7 (I don't get Java's naming convention)?
I got the same error message when trying to start Cassandra. But I notised that I only got the error when starting Cassandra as root. It worked when I started Cassandra as my local user.
It turned out that java only was configured for my local user:
$ java -version
java version "1.7.0_60"
Java(TM) SE Runtime Environment (build 1.7.0_60-b19)
Java HotSpot(TM) 64-Bit Server VM (build 24.60-b09, mixed mode)
$ sudo java -version
sudo: java: command not found
This fixed the problem:
Tell the system that you have JRE installed (update usr/local/java/jre1.7.0_60/bin/java to your current path):
$ sudo update-alternatives --install "/usr/bin/java" "java" "/usr/local/java/jre1.7.0_60/bin/java" 1
Set the new JRE as default:
$ sudo update-alternatives --set java /usr/local/java/jre1.7.0_60/bin/java
Now java is installed for root and Cassandra can be started as root without the error message.
Per documentation: http://wiki.helioviewer.org/wiki/Apache_Cassandra_Installation
Set JAVA_HOME
Make sure JAVA_HOME is set: echo $JAVA_HOME
So make sure JAVA_HOME is pointing to /path/to/jdk7
To resolve this problem I changed $JAVA_HOME environment variable to the path I found it from:
System Preferences -> Java -> java (tab in Java Control Panel) -> View -> Path
I had two version of java and the default one was the old version of java.
See this CASSANDRA-11716 issue. The solution posted there worked for me.
Nothing above worked for me.I was trying to run cassandra with supervisor and was getting java error.So I figured out that I had to just set java path in cassandra.in.sh. I just had to set JAVA_HOME=/usr/local/jdk1.8.0_171 and save it and this worked for me.
I have faced a similar issue when installing DSE 4.6 on Linux. Issue is resolved when you set JAVA_HOME (as root) to the directory where JRE 1.7.x installed.
There appears to be a newer issue now that Java 7 update 101 has been released. I installed this version which broke Cassandra:
yum install java-1.7.0-oracle-1.7.0.101-1jpp.1.el7.x86_64
Installing a previous version (update 99) fixed the issue:
yum install java-1.7.0-oracle-1.7.0.99-1jpp.1.el7.x86_64
I'm guessing somewhere in the cassandra startup script a Regex is written for 2 characters in the update version, not 3.
This is caused by a bug in Cassandra: https://issues.apache.org/jira/browse/CASSANDRA-11661
I started off with CentOS and OpenJDK 1.7
# java -version
java version "1.7.0_25"
OpenJDK Runtime Environment (rhel-2.3.10.4.el6_4-x86_64)
OpenJDK 64-Bit Server VM (build 23.7-b01, mixed mode)
In order to run a specific application, I want to use Oracle's Java 1.6, provided from an RPM.
I copied the Oracle binary to a specific new directory:
# pwd
/oracleJava/jdk-6u45-linux-x64-rpm
I extracted the binary and it gave me the following files:
# ls
jdk-6u45-linux-amd64.rpm
sun-javadb-core-10.6.2-1.1.i386.rpm sun-javadb-javadoc-10.6.2-1.1.i386.rpm
sun-javadb-client-10.6.2-1.1.i386.rpm sun-javadb-demo-10.6.2-1.1.i386.rpm
sun-javadb-common-10.6.2-1.1.i386.rpm sun-javadb-docs-10.6.2-1.1.i386.rpm
I installed the RPM and the rpm utility believes that it installed properly:
rpm -q jdk
jdk-1.6.0_45-fcs.x86_64
# rpm -Uvh ./*.rpm
Preparing... ########################################### [100%]
package jdk-2000:1.6.0_45-fcs.x86_64 is already installed
# rpm -Uvh sun-javadb-*.rpm
[I omit the feedback because it generates a formatting error]
#
However, the Java version just shows 1.7
# java -version
java version "1.7.0_25"
OpenJDK Runtime Environment (rhel-2.3.10.4.el6_4-x86_64)
OpenJDK 64-Bit Server VM (build 23.7-b01, mixed mode)
In other words, I was expecting the Oracle files to give me some new /java directory somewhere, with a new java executable that would return a different answer for "java -version"
I need that new directory so that I can set JAVA_HOME and use the 1.6 version of Java.
Helpful suggestions would be greatly appreciated. Thanks in advance.
The Oracle JDK RPMs are horrible.
They do not register with the alternatives system.
They do not Provide (in RPM terms) "java"
They have messed up their RPM 'version string' and rely on Epoch (...)
All versions of the JDK (i.e. 1.6 vs 1.7) have the same Epoch
In order to quickly remedy your problem you can run the following:
/usr/sbin/alternatives --install /usr/bin/java java /usr/java/default/bin/java 20000
It will register and prefer the Oracle java installation as an alternative. OpenJDK has weight 16000; here we register with 20000. Once you've run this command you can switch between java versions by using the (already mentioned) alternatives --config java command.
As for a less quick fix you can use my virtual java package. It's quite possibly not perfect (I'm open for improvements ;) ), but it Provides java (making my apache-tomcat package happy) and registers with the alternatives system. This virtual package simply depends on jdk...you can find it here: https://github.com/keystep/virtual-java-rpm
Run the following command to see if your JVM is getting listed.
sudo update-alternatives --config java
If your JVM gets listed select it.
The problem is that Oracle's RPMs are (wilfully IMO!) ignorant of the "alternatives" system.
Instead, they install stuff in a non-standard place (/usr/java) and then expect the user / system administrator to mess with the PATH variable ... by hand.
It is a nuisance!
So what has probably happened in your case is that your JDK / JRE has been installed in a subdirectory of /usr/java ... but since you haven't added the relevant bin subdirectory to the front of your PATH you are still picking up the OpenJDK tools via the java command name.
You can fix this after the fact by using "alternatives" to configure and then select the Oracle commands. But it is messy, especially if you want the JDK tools as well. (There are a lot of them!)
Please check that whether your JAVA_HOME points to JDK 6 using echo $JAVA_HOME. In order change your JAVA_VERSION to Java 6, you need to point to the Java development KIT 6. You also need to add the bin directory to the $PATH variable. Please ensure that JDK6 bin directory comes in the $PATH prior to other JDK bin,if any. You can check the version of your Java in the environment by command java -version.The other answer by learningloop is very perfect to switch between different Java configurations
Try to the following method
delete OpenJDK folder from
/usr/lib/jvm
I had same problem and got solution through this method
On my Red Hat server, java -version outputs;
$ java -version
java version "1.6.0_27"
Java(TM) SE Runtime Environment (build 1.6.0_27-b07)
Java HotSpot(TM) 64-Bit Server VM (build 20.2-b06, mixed mode)
$
However, neither PATH, nor JAVA_HOME environment variables are set. Likewise, JAVA_HOME is not set on ~/.bash* files.
Why and how my server uses this version of Java while two other versions of Java are installed as well?
Firstly, JAVA_HOME is not involved in this. (JAVA_HOME is used conventionally by wrapper scripts, etc for applications that use Java ... but not by any of the Java executables themselves.)
Second, you are probably running java via a symlink managed by the alternatives program. (RHEL and similar distros use this utility to allow you to select different versions of utilities installed on the same system.)
Either way, running the following will help you figure out what is going on.
$ ls -l `which java`
(Then following the chain of symlinks until you get to the actual executable.)
Which executable runs depends on PATH variable. Double check it. It can't run if not set it is impossible unless you have some strange Linux config.
If Java executable is in current directory, it would run by ./java. Since it runs with just java it is somewhere in the PATH.