$ 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
Related
I have been trying to setup elasticsearch in windows7 machine by following https://www.elastic.co/guide/en/elasticsearch/reference/current/_installation.html
I was able to download, unzip but when running ./elasticsearch, I get the below error,
Error: Could not find or load main class
org.elasticsearch.tools.JavaVersionChecker
Elasticsearch requires at least Java 8 but your Java version from C:\Program
Files\Java\jdk1.8.0_131/bin/java does not meet this requirement
I have verified Java versions installed and they look fine,
$ java -version
java version "1.8.0_131"
Java(TM) SE Runtime Environment (build 1.8.0_131-b11)
Java HotSpot(TM) 64-Bit Server VM (build 25.131-b11, mixed mode)
$ javac -version
javac 1.8.0_131
Can someone point out where I am wrong ?
In run Elasticsearch in Windows, you should run with elasticsearch.bat not ./elasticsearch directly:
And now we are ready to start our node and single cluster (Windows users should run the elasticsearch.bat file):
Seems like you don't have right permissions. Try to set them to 774 and check again:
sudo chmod 774 -R elasticsearch-6.3.2/
My os is Ubuntu 16.04 LTS.
$ cat /etc/profile # part content of this file
JAVA_HOME=/usr/local/java/jdk1.8.0_101
JRE_HOME=$JAVA_HOME/jre
PATH=$PATH:$JAVA_HOME/bin:$JRE_HOME/bin
export JAVA_HOME
export JRE_HOME
export PATH
$ echo $JAVA_HOME
/usr/local/java/jdk1.8.0_101
$ java -version
java version "1.7.0_79"
Java(TM) SE Runtime Environment (build 1.7.0_79-b15)
Java HotSpot(TM) 64-Bit Server VM (build 24.79-b02, mixed mode)
$ ls /usr/local/java/
jdk1.7.0_79/ jdk1.8.0_101/
Why is my java version still jdk7?
Ubuntu has ability to work with multiple java versions. In your case, it just means that it has both JDK 7 and JDK 8 installed in your system but is using JDK 7.
To switch from one java version to another, you can use sudo update-alternatives --config java. This will list all JDKs installed in your system, just enter the number corresponding to JDK 8 and it should switch to JDK 8.
Run which java in your command shell. That will tell you where the java command you are running is coming from.
I suspect that is will tell you "/usr/bin/java" ... because this:
PATH=$PATH:$JAVA_HOME/bin:$JRE_HOME/bin
puts your new bin directories onto the end of the search path, not the beginning.
However, the better way to do this would be to use alternatives as suggested by another Answer. (With a custom installation in "/usr/local" this will require some fiddling around to get "alternatives" to understand the alternative.)
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
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.
I upgraded java on my osx 10.9.4 machine using the suggested method from the java web site
It successfully updated, but when trying to run Eclipse I get an error:
Version 1.6.0_65 of the JVM is not suitable for this product.
Version 1.7 or greater is required.
When I access java settings through the applet in the control panel, it shows Java 7 Update 65, but when I type java -version in the console, it shows 1.6.0_65 (response shown below):
| => java -version
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)
As far as I know, there is only one java on the box. "which java" returns /usr/bin/java and type -a java returns only /usr/bin/java also. /usr/bin/java is obviously the older version, but I'd like to use the updated one. Can someone please tell me how to update the /usr/bin/java version and/or how to link the applet version so that Eclipse will use the updated one?
Take a look at oracle documentation here:
http://docs.oracle.com/javase/7/docs/webnotes/install/mac/mac-jdk.html
It says:
To run a different version of Java, either specify the full path, or
use the java_home tool:
/usr/libexec/java_home -v 1.7.0_06 --exec javac -version
The /usr/libexec/java_home is a link to your jdk directory that should be located under:
/Library/Java/JavaVirtualMachines/jdk<major>.<minor>.<macro[_update]>.jdk
I think your java_home link is pointing to your jdk6. You can check it doing a ls -l /usr/libexec/