"$JAVA_HOME is not set" when running kiji-rest in init.d

[weiser]

I'm trying to run the kiji-rest.initd script, but I'm getting the above error.

I've got the /opt/wibi directory set up correctly:

vagrant@granary:/usr/local/kiji/kiji-rest-1.4.0$ ll /opt/wibi/kiji-rest/
total 60
drwxr-xr-x 7 root root  4096 Aug 11 15:52 ./
drwxr-xr-x 7 root root  4096 Aug 11 15:52 ../
drwxr-xr-x 2 5001 5001  4096 Aug 12 08:55 bin/
drwxr-xr-x 4 5001 5001  4096 Jul  2 00:08 clients/
drwxr-xr-x 2 5001 5001  4096 Jul  2 00:08 conf/
drwxr-xr-x 3 root root  4096 Aug 11 15:52 docs/
drwxr-xr-x 2 5001 5001 12288 Jul  2 00:08 lib/
-rw-r--r-- 1 5001 5001 11358 Jul  2 00:29 LICENSE.txt
-rw-r--r-- 1 5001 5001    85 Jul  2 00:29 NOTICE.txt
-rw-r--r-- 1 5001 5001  3761 Jul  2 00:29 README.md
-rw-r--r-- 1 5001 5001  3969 Jul  2 00:29 RELEASE_NOTES.txt

and the init.d file is in /etc/init.d:

vagrant@granary:/usr/local/kiji/kiji-rest-1.4.0$ ls /etc/init.d | grep kiji
kiji-rest

But when I do sudo service kiji-rest status, I get "$JAVA_HOME is not set".

To get around this, I added the following to kiji-rest.initd (at the beginning of the file):

# I took this from the /etc/init.d/hadoop-hdfs-namenode

# Autodetect JAVA_HOME if not defined
if [ -e /usr/libexec/bigtop-detect-javahome ]; then
  . /usr/libexec/bigtop-detect-javahome
elif [ -e /usr/lib/bigtop-utils/bigtop-detect-javahome ]; then
  . /usr/lib/bigtop-utils/bigtop-detect-javahome
fi

it seems that other Hadoop subsystems use this approach to setting $JAVA_HOME, but kiji-rest isn't.

Have I made a gaff? Should I make a PR for this?

[ANithian]

Hi David,

Thanks for your note. In the kiji-rest script, I borrwed a few lines from bigtop:

attempt to find java (stolen from bigtop)

if [ -z "$JAVA_HOME" ]; then
for candidate in
/usr/lib/jvm/java-6-sun
/usr/lib/jvm/java-1.6.0-sun-1.6.0./jre/
/usr/lib/jvm/java-1.6.0-sun-1.6.0.
/usr/lib/jvm/j2sdk1.6-oracle
/usr/lib/jvm/j2sdk1.6-oracle/jre
/usr/lib/j2sdk1.6-sun
/usr/java/jdk1.6*
/usr/java/jre1.6*
/Library/Java/Home
/usr/java/default
/usr/lib/jvm/default-java
/usr/lib/jvm/java-openjdk
/usr/lib/jvm/jre-openjdk
/usr/lib/jvm/java-1.6.0-openjdk-1.6.*
/usr/lib/jvm/jre-1.6.0-openjdk* ; do
if [ -e "$candidate/bin/java" ]; then
export JAVA_HOME="${candidate}"
break
fi
done
fi

if [ -z "$JAVA_HOME" ]; then
echo "$JAVA_HOME not set."
exit 1
fi

Can you let me know which of those conditions isn't firing or if there are new conditions that I should be taking into account? I guess I could also check for bigtop and if all else fails use the borrowed stuff.

Also you may want to compare the kiji-rest and kiji-rest.initd on master against what you have in case there have been some patches. I know I've fixed a few errors here and there.

Thanks!
Amit

[weiser]

Initially, what I noticed is that if I did echo $JAVA_HOME in kiji-rest.initd it would print nothing. That is because service strips environment variables.

The files of what I'm using (kiji-rest-1.4.0) look identical (at least in this case).

Since Hadoop is a prerequisite for Kiji, it seems reasonable to use the bigtop stuff since it is already there.

[ANithian]

Sure but shouldn't this part still try and determine something?
for candidate in
/usr/lib/jvm/java-6-sun
/usr/lib/jvm/java-1.6.0-sun-1.6.0./jre/
/usr/lib/jvm/java-1.6.0-sun-1.6.0.
/usr/lib/jvm/j2sdk1.6-oracle
/usr/lib/jvm/j2sdk1.6-oracle/jre
/usr/lib/j2sdk1.6-sun
/usr/java/jdk1.6*
/usr/java/jre1.6*
/Library/Java/Home
/usr/java/default
/usr/lib/jvm/default-java
/usr/lib/jvm/java-openjdk
/usr/lib/jvm/jre-openjdk
/usr/lib/jvm/java-1.6.0-openjdk-1.6.*
/usr/lib/jvm/jre-1.6.0-openjdk* ; do
if [ -e "$candidate/bin/java" ]; then
export JAVA_HOME="${candidate}"
break
fi
done
fi

By chance are you running Java 7? I may update this check to look for Java 7 stuff instead of 6.

While you're right that Hadoop is a pre-req for Kiji, the initial design of the deployment of KijiREST was that you need not deploy it on a box that has the hadoop binaries (hence why the package is the way it is). That being said, having the script at least run the bigtop stuff if it's present doesn't hurt so we'd be more than happy to accept a patch on that OR to save you some time, simply file a JIRA on http://jira.kiji.org and I'll put it in pretty quickly since I'm iterating on some other KijiREST changes now anyways.

Thanks!

[weiser]

I'd like to contribute a PR for this. Can I just fork this and submit here? Or is there something that needs to be done in JIRA?

[ANithian]

These instructions may be a bit dated but basically:

1. File an issue at jira.kiji.org
2. Sign up for a reviewboard account @ review.kiji.org
3. Submit review against issue filed

I'm asking for details on the rest of the flow since there used to be a contributor form but I don't recall the specifics. Do steps 1-3 and I'll follow up after that shortly!

[weiser]

OK, cool. I'll do that, but I just put up #6 as a preview

[ANithian]

Sounds good thanks! Also can you look at my previous question regarding the detection of JAVA_HOME (I understand the situation when your vars are cleared but curious why the auto-detection via the existing mechanism doesn't work for you).

[weiser]

for candidate in \
/usr/lib/jvm/java-6-sun \
/usr/lib/jvm/java-1.6.0-sun-1.6.0./jre/ \
/usr/lib/jvm/java-1.6.0-sun-1.6.0. \
/usr/lib/jvm/j2sdk1.6-oracle \
/usr/lib/jvm/j2sdk1.6-oracle/jre \
/usr/lib/j2sdk1.6-sun \
/usr/java/jdk1.6* \
/usr/java/jre1.6* \
/Library/Java/Home \
/usr/java/default \
/usr/lib/jvm/default-java \
/usr/lib/jvm/java-openjdk \
/usr/lib/jvm/jre-openjdk \
/usr/lib/jvm/java-1.6.0-openjdk-1.6.* \
/usr/lib/jvm/jre-1.6.0-openjdk* ; do
if [ -e "$candidate/bin/java" ]; then
export JAVA_HOME="${candidate}"
echo $JAVA_HOME
break
fi
done

yields /usr/lib/jvm/java-7-oracle

[weiser]

I'm trying to submit a review at https://review.kiji.org/r/new/ but I get an error when submitting the patch: "The file 'kiji-rest/src/main/scripts/kiji-rest.initd' (rd946a7f) could not be found in the repository" which seems weird (I created the patch from my forked git repo). :(

[ANithian]

Grumble :-( Given the nature of this patch, I can merge it in manually can you paste the diff in the comment? Sorry for the trouble! Also did you file a JIRA issue on jira.kiji.org? Lastly, I'm curious to reproduce, looks like you're using vagrant, is there a VagrantFile you can share with me so I can test this too?

[weiser]

Sadly, I can't share the vagrantfile because it has company info in it.

I put the patch here.

I did file a bug in the jira.

[ANithian]

Thanks! This should go in shortly.

Cheers
Amit

On Thu, Aug 14, 2014 at 3:52 PM, David Weiser [email protected]
wrote:

Sadly, I can't share the vagrantfile because it has company info in it.

I put the patch here
https://gist.github.com/davidann/1f3455e64b7051ce0ef1.

I did file a bug in the jira https://jira.kiji.org/browse/REST-151.

—
Reply to this email directly or view it on GitHub
#5 (comment).

[weiser]

Good, thanks!:)