Bugzilla Bug 103024

There is a line in /etc/conf.d/hsqldb that reads JAVA_EXECUTABLE=$(which java). 
This fails because java is not in root's path and the error appears every time 
depscan.sh runs. It should be JAVA_EXECUTABLE=$(java-config -J) though I'm not 
sure if the line is even needed at all since this env is not used in /etc/init.
d/hsqldb but neither are any of the other envs for that matter.

In here the problem is that /usr is not mounted when the depscan.sh is run. I
already told this problem to axxo so he is also aware of this. I suggested we
put /usr/bin/java in there with the new setup but for some reason he did not
like it. The other possibility is to evaluate to command later in
/etc/init.d/hsqldb.

Oh sorry, what I said wasn't quite right was it? It was very late when I made 
this bug and I somehow totally managed to forget what the point of "which" was.
 :P

fixed

Hmmm. Even though this bug is marked RESOLVED FIXED, I still got the same
problem.

Yesterday I've emerged hsqldb-1.7.3.1-r1 and while starting it from root's
console via "/etc/init.d/hsqldb start" was okay, the server never came up after
doing "rc-update add hsqldb default" and reboot. Instead it only displayed:

 * Starting HSQL Database ...
Config file '/etc/conf.d/hsqldb' does not set one or more of following
variables
    JAVA_EXECUTABLE, HSQLDB_JAR_PATH, SERVER_HOME                          
[!!]

I've done a small investigation and came up with (probably) suboptimal
solution.
I modified the /etc/conf.d/hsqldb script in order to make sure that the correct
'java' executable is present in PATH environment variable.

However, I think this should be attacked in a different way (even though I have
a solution which works for me).

Created an attachment (id=72276) [details]
conf.d_hsqldb.diff

A small and very Gentoo-specific addition to the /etc/conf.d/hsqldb
to make sure that 'java' executable is present in PATH variable.

Sir No: Are you using one of the latest baselayouts? Maybe this has something
to
do with the fact that it restricts the stuff that gets to the init script
environment.

(In reply to comment #6)
> Sir No: Are you using one of the latest baselayouts? Maybe this has something
> to do with the fact that it restricts the stuff that gets to the init script
> environment.

I'm not sure. For me it's:

# equery list baselayout
[ Searching for package 'baselayout' in all categories among: ]
 * installed packages
[I--] [  ] sys-apps/baselayout-1.11.13-r1 (0)

and I run mostly x86 packages, unless I have no other choice.

Have you tried running env-update?

Ok, let's forget about that. There is a simple workaround for everybody
interested:

In /etc/conf.d/hsqldb the line
JAVA_EXECUTABLE=$(which java 2>/dev/null)

should be changed to:
JAVA_EXECUTABLE=$(java-config --java 2>/dev/null)

Even better is to patch the original hsqldb-1.7.3.1-r1.ebuild to prevent
the problem completely. Patch follows.

Created an attachment (id=72734) [details]
hsqldb-1.7.3.1-r1.ebuild.patch

A patch to change '$(which java)' to '$(java-config --java)' in the
hsqldb-1.7.3.1-r1.ebuild file.

BTW. $(which java) is wrong, because at the time the hsqldb service starts
the /usr directory might not be mounted. So, using $(java-config --java)
is the preferred way to get the full path to the 'java' executable.