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 attachment 72276 [details, diff] 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 attachment 72734 [details, diff] 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.
