Bug 428520 - hsqldb gets "JAVA_EXECUTABLE ... is set to a non-file"
hsqldb gets "JAVA_EXECUTABLE ... is set to a non-file"
Product: Fedora
Classification: Fedora
Component: hsqldb (Show other bugs)
All Linux
low Severity low
: ---
: ---
Assigned To: Deepak Bhole
Fedora Extras Quality Assurance
: Reopened
Depends On:
  Show dependency treegraph
Reported: 2008-01-12 14:54 EST by Michal Jaegermann
Modified: 2011-06-03 20:56 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-01-09 02:35:29 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
a content of /var/lib/alternatives/java on F8 "from scratch" installation (1.98 KB, text/plain)
2008-01-16 18:12 EST, Michal Jaegermann
no flags Details

  None (edit)
Description Michal Jaegermann 2008-01-12 14:54:43 EST
Description of problem:

On a freshly installed F8 system executing 'service hsqldb status',
and similar, brings:

JAVA_EXECUTABLE or HSQLDB_JAR_PATH in '/etc/sysconfig/hsqldb' is set to a non-file.

The trouble is that there is the following code in /etc/sysconfig/hsqldb:
. /etc/java/java.conf


but first - JAVA_HOME is not set in /etc/java/java.conf,
second - even it is set somewhere else in enviromenment then
/etc/sysconfig/hsqldb executes in such context than it is not
picked up, and third - naively uncommenting in /etc/java/java.conf
a line '#JAVA_HOME=$JVM_ROOT/java' will get clearly wrong results.

Replacing in /etc/sysconfig/hsqldb the quoted fragement with

. /etc/java/java.conf


at least on F8 would have a fighting chance (even if rather
/usr/lib/jvm/java-1.5.0-gcj- should be used by default).

Version-Release number of selected component (if applicable):
hsqldb- and earlier
Comment 1 Jon Prindiville 2008-01-16 14:43:25 EST
This is likely best solved by changing /etc/sysconfig/hsqldb to read:

or (equivalently, "/usr/lib/jvm" is a symlink):

Comment 2 Deepak Bhole 2008-01-16 14:50:31 EST
/usr/lib/jvm/java is the default jvm set by alternatives. I would propose that
we add a line in /etc/sysconfig/hsqldb:


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)
Comment 3 Michal Jaegermann 2008-01-16 15:41:27 EST
> 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.

Comment 4 Deepak Bhole 2008-01-16 16:16:12 EST
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?
Comment 5 Michal Jaegermann 2008-01-16 16:49:22 EST
> Which jvm is installed on the system where that dir doesn't exist?

$ grep java /var/log/rpmpkgs

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

On a system which went through updates there is also
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
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.
Comment 6 Thomas Fitzsimmons 2008-01-16 17:59:45 EST
Does the file /var/lib/alternatives/java exist on your system?
Comment 7 Michal Jaegermann 2008-01-16 18:12:20 EST
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.
Comment 8 Jon Prindiville 2008-01-18 09:13:46 EST
Michal, is /etc/alternatives/java a valid symlink (to a Java binary) on either
of the systems?
Comment 9 Michal Jaegermann 2008-01-18 12:16:37 EST
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.
Comment 10 Jon Prindiville 2008-01-21 14:40:07 EST
Anyone object to my setting "JAVA_EXECUTABLE=/etc/alternatives/java"?
Comment 11 Thomas Fitzsimmons 2008-01-21 15:11:39 EST
(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.
Comment 12 Michal Jaegermann 2008-01-21 16:08:59 EST
> 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
in /etc/sysconfig/hsqldb would solve the issue.
Comment 13 Jon Prindiville 2008-01-22 11:07:58 EST
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)
Comment 14 Fedora Update System 2008-01-24 16:45:07 EST
hsqldb- 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'
Comment 15 Fedora Update System 2008-01-24 17:00:40 EST
hsqldb- 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'
Comment 16 Fernando Nasser 2008-10-20 10:42:18 EDT
Hi Michal, did the fix work?
Comment 17 Michal Jaegermann 2008-10-20 13:42:14 EDT
> Hi Michal, did the fix work?

One would think that you can check that as trivially as I can.

On F9 installation with hsqldb- 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



The last line prints "/usr/lib/jvm/jre /usr/lib/jvm/jre/bin/java" and
none of these exists.  The following are present, though:


BTW - '/etc/java/java.conf' comes from jpackage-utils-1.7.5-1jpp.2.fc9
installed on "Wed 23 Jul 2008"
Comment 18 Fernando Nasser 2008-10-21 16:39:24 EDT
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.
Comment 19 Michal Jaegermann 2008-10-21 17:31:37 EDT
> 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-
and for java-1.5.0-gcj- 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.
Comment 20 Michal Jaegermann 2008-10-22 16:43:30 EDT
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

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.
Comment 21 Bug Zapper 2008-11-26 04:24:44 EST
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: 
Comment 22 Bug Zapper 2009-01-09 02:35:29 EST
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.
Comment 23 Jérôme Benoit 2011-06-03 20:56:08 EDT
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). 


Note You need to log in before you can comment on or make changes to this bug.