Summary: | hsqldb: $(which java) in /etc/conf.d/hsqldb fails | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | James Le Cuirot <chewi> |
Component: | Current packages | Assignee: | Java team <java> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | wiktorw |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
conf.d_hsqldb.diff
hsqldb-1.7.3.1-r1.ebuild.patch |
Description
James Le Cuirot
![]() 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.
|