Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Resolve symlinked java command to find home #6639

Merged
merged 8 commits into from Mar 30, 2021

Conversation

headius
Copy link
Member

@headius headius commented Mar 30, 2021

This PR fixes #6637 by fully resolving any symlinks between the java command (found from $JAVACMD or java in PATH) before using that command's path to determine $JAVA_HOME.

The issue affects systems without $JAVA_HOME set, but that have a java command in PATH that resolves to a $JAVA_HOME/bin/java through a series of symlinks (e.g. CentOS).

This PR also exports JRUBY_HOME, JAVACMD, and JAVA_HOME so they will be seen by the JRuby process and subprocesses, avoiding recalculating this home or accidentally using a different JDK for additional JRuby launches.

I have added a test case for the symlink situation.

On many Linux systems, the installed `java` command will live in
/usr/bin and point via a chain of symlinks to the actual JDK home
installation under (for example) /usr/lib/jvm/<java-home>. This
symlinking interferes with our detecting where Java actually
lives, leading to issues like jruby#6637.

This patch uses existing logic for resolving a trail of symlinks,
allowing us to dig down to the actual binary `java` and from there
determine its JAVA_HOME.

Fixes jruby#6637.

See also jruby/jruby-launcher#34 which will need a similar fix in
C.
These should be visible from within the launched JRuby process.
@headius headius added this to the JRuby 9.2.18.0 milestone Mar 30, 2021
@headius headius requested a review from enebo March 30, 2021 18:11
@headius
Copy link
Member Author

headius commented Mar 30, 2021

First attempt at a test failed, indicating that the JDK installs on Ubuntu also symlink <jdk home>/bin/java to <jdk home>/jre/bin/java so fully resolving this path may potentially walk out of the JDK into a JRE root. I am unsure if this would be a problem in practice... we do not require the JDK and the JRE concept is going away.

There is no standard way in POSIX shell to determine the target
of a symlink, so we are forced to use readlink.
export will hide the failure of the command on the RHS used as the
value, so export only the variable names.
@headius
Copy link
Member Author

headius commented Mar 30, 2021

Additional improvements thanks to @mrnoname1000:

  • Use variable for return from function resolve_symlinks to avoid forking a subprocess.
  • export vars separately from assignment, since that will mask failures if the variable's RHS command fails.

@headius headius merged commit 41b0e9d into jruby:jruby-9.2 Mar 30, 2021
@headius headius deleted the resolve_java_symlink branch March 30, 2021 20:47
@headius
Copy link
Member Author

headius commented Mar 31, 2021

From de400b6:

Remove export of key discovered paths

I decided I am not comfortable with this change, since it would
mean launching a subprocess JRuby with a different home or Java
would require clearing these variables rather than just pointing
at a new jruby or java executable.

headius added a commit that referenced this pull request Mar 31, 2021
I decided I am not comfortable with this change, since it would
mean launching a subprocess JRuby with a different home or Java
would require *clearing* these variables rather than just pointing
at a new jruby or java executable.

See #6639.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

1 participant