Bug 428520
Summary: | hsqldb gets "JAVA_EXECUTABLE ... is set to a non-file" | ||||||
---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Michal Jaegermann <michal> | ||||
Component: | hsqldb | Assignee: | Deepak Bhole <dbhole> | ||||
Status: | CLOSED WONTFIX | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
Severity: | low | Docs Contact: | |||||
Priority: | low | ||||||
Version: | 8 | CC: | fnasser, jerome.benoit, patrickm | ||||
Target Milestone: | --- | Keywords: | Reopened | ||||
Target Release: | --- | ||||||
Hardware: | All | ||||||
OS: | Linux | ||||||
Whiteboard: | |||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2009-01-09 07:35:29 UTC | Type: | --- | ||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Attachments: |
|
Description
Michal Jaegermann
2008-01-12 19:54:43 UTC
This is likely best solved by changing /etc/sysconfig/hsqldb to read: JAVA_EXECUTABLE=/usr/lib/jvm/java/bin/java or (equivalently, "/usr/lib/jvm" is a symlink): JAVA_EXECUTABLE=/etc/alternatives/java_sdk/java/bin/java Thoughts? /usr/lib/jvm/java is the default jvm set by alternatives. I would propose that we add a line in /etc/sysconfig/hsqldb: JAVA_HOME=${JAVA_HOME:-/usr/lib/jvm/java} right above JAVA_EXECUTABLE=${JAVA_HOME}/bin/java This will ensure that the alternatives-set jvm gets used each time -- be it Icedtea or GCJ (or any other jpp compliant jvm installation) > Thoughts?
Count me "Java naive". Any reasonable default for $JAVA_EXECUTABLE
is fine with me. OTOH I looked at two different F8 installations,
one done "from scratch" and the other with a long history of
upgrades, and on none of those /usr/lib/jvm/java exists. I know
that in both cases nobody was messing up with java installations.
OTOH a link /usr/lib/jvm/jre/ does exist, it goes through alternatives,
and it looks like a reasonable candidate for JAVA_HOME.
/usr/lib/jvm/jre/bin/java is indeed some executable.
Any F8 system with a proper jvm installation (i.e. gcj, or icedtea) should have /usr/lib/jvm/java ... if that dir doesn't exist, it is a bug. Which jvm is installed on the system where that dir doesn't exist? > Which jvm is installed on the system where that dir doesn't exist?
$ grep java /var/log/rpmpkgs
java-1.5.0-gcj-1.5.0.0-17.fc8.i386.rpm
java-1.7.0-icedtea-1.7.0.0-0.19.b21.snapshot.fc8.i586.rpm
java-1.7.0-icedtea-plugin-1.7.0.0-0.19.b21.snapshot.fc8.i586.rpm
java_cup-0.10-0.k.6jpp.1.i386.rpm
tzdata-java-2007k-1.fc8.noarch.rpm
This is on a system installed "from scratch". Looking at 'install.log',
which is still there, all five packages were installed by anaconda
while building up an initial system and some updated afterfwards.
Definitely no /usr/lib/jvm/java although one can find
/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/
/usr/lib/jvm/java-1.7.0-icedtea-1.7.0.0/
On a system which went through updates there is also
/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/
with no files in it but a bunch of links pointing to files
from libgcj-4.1.2-33.x86_64 package and one dangling link
/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre/lib/security/java.security
to /usr/lib/security/classpath.security (which does not exist).
This is x86_64 installation so that link really should be to
an existing /usr/lib64/security/classpath.security but it is not.
Does the file /var/lib/alternatives/java exist on your system? Created attachment 291909 [details] a content of /var/lib/alternatives/java on F8 "from scratch" installation > Does the file /var/lib/alternatives/java exist on your system? That system is not precisely "mine" but I have an access to it. :-) A content of this file, not edited in any way, is attached. Michal, is /etc/alternatives/java a valid symlink (to a Java binary) on either of the systems? In both cases /etc/alternatives/java is a link to 'java': /usr/lib/jvm/jre-1.7.0-icedtea/bin/java on one system and to /usr/lib/jvm/jre-1.7.0-icedtea.x86_64/bin/java on another. Anyone object to my setting "JAVA_EXECUTABLE=/etc/alternatives/java"? (In reply to comment #10) > Anyone object to my setting "JAVA_EXECUTABLE=/etc/alternatives/java"? OK, I think I know what the problem is. Michal, do you have a -devel Java package installed? Either java-1.5.0-gcj-devel or java-1.7.0-icedtea-devel? /usr/lib/jvm/java is an alternatives-installed symlink, installed by the -devel post script. If hsqldb requires only a runtime environment, then the correct fix is to set JAVA_EXECUTABLE=/usr/lib/jvm/jre/bin/java. This will always point to the currently-selected alternative's java command. /usr/lib/jvm/jre is an alternatives-installed symlink installed by the base packages' (java-1.7.0-icedtea and java-1.5.0-gcj) post scripts. > Michal, do you have a -devel Java package installed? Nope. See comment #5 for a full list of packages present. > then the correct fix is to set JAVA_EXECUTABLE=/usr/lib/jvm/jre/bin/java That is what I suggested in comment #3. It looks that JAVA_HOME=${JAVA_HOME:-/usr/lib/jvm/jre} in /etc/sysconfig/hsqldb would solve the issue. Michal, the new package is pending to go into F8's testing repo. (It's also here: http://koji.fedoraproject.org/koji/buildinfo?buildID=32395) hsqldb-1.8.0.9-1jpp.1.fc8 has been pushed to the Fedora 8 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update hsqldb' hsqldb-1.8.0.9-1jpp.1.fc7 has been pushed to the Fedora 7 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update hsqldb' Hi Michal, did the fix work? > Hi Michal, did the fix work?
One would think that you can check that as trivially as I can.
On F9 installation with hsqldb-1.8.0.9-2jpp.1.fc9 updated on "Fri 13 Jun 2008" and with '/etc/sysconfig/hsqldb' coming from that package:
# /etc/init.d/hsqldb status
JAVA_EXECUTABLE or HSQLDB_JAR_PATH in '/etc/sysconfig/hsqldb' is set to a non-file.
This is what this fragment of /etc/sysconfig/hsqldb is roughly trying to do:
. /etc/java/java.conf
JAVA_HOME=${JAVA_HOME:-/usr/lib/jvm/jre}
JAVA_EXECUTABLE=${JAVA_HOME}/bin/java
echo $JAVA_HOME $JAVA_EXECUTABLE
The last line prints "/usr/lib/jvm/jre /usr/lib/jvm/jre/bin/java" and
none of these exists. The following are present, though:
/usr/lib/jvm/jre-1.5.0
/usr/lib/jvm/jre-1.5.0-gcj
/usr/lib/jvm/jre-1.6.0
/usr/lib/jvm/jre-1.6.0-openjdk.x86_64
/usr/lib/jvm/jre-gcj
/usr/lib/jvm/jre-openjdk
BTW - '/etc/java/java.conf' comes from jpackage-utils-1.7.5-1jpp.2.fc9
installed on "Wed 23 Jul 2008"
This has nothing to do with hsqldb. /usr/lib/jvm/jre /usr/lib/jvm/jre/bin/java must exist if java is properly installed in your system. They are alternatives symlinks that point to the highest priority Java in your system. If neither gcj nor openjdk are providing it you should open a bug against those components. But check if nothing went wrong when installing those. > This has nothing to do with hsqldb. Well, if you think so then reassign the report appropriately instead of wrongly closing it. So far I see that hsqldb is broken. > /usr/lib/jvm/jre /usr/lib/jvm/jre/bin/java must exist Maybe. Only postinstall scripts for java-1.6.0-openjdk-1.6.0.0-0.18.b09.fc9 and for java-1.5.0-gcj-1.5.0.0-21.fc9 do not create anything of that sort. I just checked. I do see there: --slave /usr/lib/jvm/jre jre /usr/lib/jvm/jre-1.6.0-openjdk.x86_64 \ but when I am trying to run the whole script which included the above then it prints "numeric priority expected in /var/lib/alternatives/java". I have no idea what that is supposed to mean. Again - if you think that something else is responsible then change that bug to that something else. I have no idea what that may be. I forced somehow alternatives to create /usr/lib/jvm/jre and /usr/lib/jvm/jre/bin/java. # ls -l /usr/lib/jvm/jre lrwxrwxrwx 1 root root 21 2008-10-22 14:11 /usr/lib/jvm/jre -> /etc/alternatives/jre # rpm -qf /usr/lib/jvm/jre/bin/java java-1.6.0-openjdk-1.6.0.0-0.18.b09.fc9.x86_64 and the later is a file 38616 bytes in size. '/etc/init.d/hsqldb status' still says "JAVA_EXECUTABLE or HSQLDB_JAR_PATH in '/etc/sysconfig/hsqldb' is set to a non-file". This time this turns out to be hsqldb package postinstall script which failed to make links in hsqldb.jar and servlet.jar in /var/lib/hsqldb/lib. That depends on build-classpath from jpackage-utils but the current version of jpackage-utils was installed roughly a month after hsqldb update. Re-executing that script eventually kills a "non-file" message. All that seems to be extremely fragile. This message is a reminder that Fedora 8 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 8. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '8'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 8's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 8 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping Fedora 8 changed to end-of-life (EOL) status on 2009-01-07. Fedora 8 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed. This bug is still present on Fedora 15. One have to make the symlink by hand in /var/lib/hsqldb/lib. hsqldb.jar -> /usr/share/java/hsqldb.jar Before it was (re-installed, force upgrading do not change anything) hsqldb.jar -> hsqldb.jar (symlink to self). Cheers. |