[jira] [Commented] (SOLR-16721) Java version detection fails when `_JAVA_OPTIONS` is set

["Jan Høydahl (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/SOLR-16721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17706133#comment-17706133 ] 

Jan Høydahl commented on SOLR-16721:
------------------------------------

[~zhongruoyu]

I reproduced the issue by setting the _JAVA_OPTIONS var, and just removing the head pipe fixed it, at least for openjdk temurin. Hopefully other java flavours will also behave the same. Do you want to test with this patch? 

> Java version detection fails when `_JAVA_OPTIONS` is set
> --------------------------------------------------------
>
>                 Key: SOLR-16721
>                 URL: https://issues.apache.org/jira/browse/SOLR-16721
>             Project: Solr
>          Issue Type: Bug
>      Security Level: Public(Default Security Level. Issues are Public) 
>          Components: SolrCLI
>    Affects Versions: 9.2
>         Environment: JDK version:
> {code:java}
> openjdk version "19.0.2" 2023-01-17
> OpenJDK Runtime Environment Homebrew (build 19.0.2)
> OpenJDK 64-Bit Server VM Homebrew (build 19.0.2, mixed mode, sharing) {code}
> OS version: macOS 11, 12, 13 (x86_64 and arm64); Ubuntu 22.04 (x86_64)
>            Reporter: Ruoyu Zhong
>            Assignee: Jan Høydahl
>            Priority: Minor
>          Time Spent: 10m
>  Remaining Estimate: 0h
>
> When the environment variable {{_JAVA_OPTIONS}} is set, {{solr}} fails with the following error:
> {code:java}
> $ solr -i
> Your current version of Java is too old to run this version of Solr.
> We found major version , using command '/opt/homebrew/opt/openjdk/libexec/openjdk.jdk/Contents/Home/bin/java -version', with response:
> Picked up _JAVA_OPTIONS: -Duser.home=/Users/brew/Library/Caches/Homebrew/java_cache -Djava.io.tmpdir=/private/tmp
> openjdk version "19.0.2" 2023-01-17
> OpenJDK Runtime Environment Homebrew (build 19.0.2)
> OpenJDK 64-Bit Server VM Homebrew (build 19.0.2, mixed mode, sharing)
> Please install latest version of Java 11 or set JAVA_HOME properly. {code}
> This is because in the following version check logic (taken from [here|https://github.com/apache/solr/blob/a2f6565415663908163f9490856cf0fcfda88b41/solr/bin/solr#L166]), only first line of {{java -version}} output is examined:
> {code:java}
> JAVA_VER_NUM=$(echo "$JAVA_VER" | head -1 | awk -F '"' '/version/ {print $2}' | sed -e's/^1\.//' | sed -e's/[._-].*$//') {code}
> But as indicated in the output above, {{java}} outputs "{{{}Picked up _JAVA_OPTIONS{}}}" on the first line instead, if {{_JAVA_OPTIONS}} is set. So, the version on the second line is not picked up.
> I believe that it's [this recent change|https://github.com/apache/solr/commit/025c0305fa829baa770f62c81654af8a708753d9] (SOLR-9509), which added a pair of quotes around {{{}$JAVA_VER{}}}, that introduced this regression. This used to work in an unintended way, because Bash treated the unquoted {{$JAVA_VER}} variable as an array of separate arguments and output that in a single line. But after introducing the double quotes, the newlines in {{$JAVA_VER}} are now preserved.
> {code:java}
> $ JAVA_VER="$(java -version 2>&1)"
> $ echo $JAVA_VER
> Picked up _JAVA_OPTIONS: -Duser.home=/Users/ruoyu/Library/Caches/Homebrew/java_cache -Djava.io.tmpdir=/private/tmp openjdk version "19.0.2" 2023-01-17 OpenJDK Runtime Environment Homebrew (build 19.0.2) OpenJDK 64-Bit Server VM Homebrew (build 19.0.2, mixed mode, sharing)
> $ echo "$JAVA_VER"
> Picked up _JAVA_OPTIONS: -Duser.home=/Users/ruoyu/Library/Caches/Homebrew/java_cache -Djava.io.tmpdir=/private/tmp
> openjdk version "19.0.2" 2023-01-17
> OpenJDK Runtime Environment Homebrew (build 19.0.2)
> OpenJDK 64-Bit Server VM Homebrew (build 19.0.2, mixed mode, sharing) {code}
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org