[
https://issues.apache.org/jira/browse/SOLR-16733?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason Gerlowski resolved SOLR-16733.
------------------------------------
Fix Version/s: main (10.0)
9.3
Resolution: Resolved
Ah, ok. I've updated the issue description as Kevin suggested.
With that done I'm going to close this out. Solr 9.2, etc. still have this
problem when running JDK20 on Mac, but we've flagged this in our release notes
and done our best to surface the issue to developers as well via a gradle
error. We can reopen later if additional steps need to be taken.
> Solr fails to start on macOS with OpenJDK 20
> --------------------------------------------
>
> Key: SOLR-16733
> URL: https://issues.apache.org/jira/browse/SOLR-16733
> Project: Solr
> Issue Type: Bug
> Components: cli
> Affects Versions: 9.2
> Environment: OS: macOS 13 (Ventura), on x86_64
> (Note: This issue occurred on all combinations of macOS \{11, 12, 13} and
> \{x86_64, arm64}. It is not reproducible on Linux.)
> Java:
> {code:java}
> $ java -version
> openjdk version "20" 2023-03-21
> OpenJDK Runtime Environment (build 20+36-2344)
> OpenJDK 64-Bit Server VM (build 20+36-2344, mixed mode, sharing) {code}
>
>
> Reporter: Ruoyu Zhong
> Assignee: Jason Gerlowski
> Priority: Minor
> Fix For: main (10.0), 9.3
>
> Attachments: solr-8983-console.log, solr.log, solr_gc.log
>
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> EDIT (Summary): The ultimate cause of this issue is [the OpenJDK bug detailed
> here|https://bugs.openjdk.org/browse/JDK-8308678], which has been fixed in
> Java 21 but will not be addressed in Java 20.
> Users may partially workaround the issue by disabling the JVM's Security
> Manager, which happens to invoke the faulty JDK API on Solr startup on Macs.
> However doing so is not advisable as the Security Manager plays an important
> role in securing Solr, and Solr may use the faulty JDK API in other ways even
> with the Security Manager disabled. It's the community's advice that Solr
> admins steer clear of Java 20 entirely, if running on Mac.
> ----
> Solr failed to start on macOS (versions: 11, 12, 13; archs: x86_64, arm64)
> with OpenJDK 20. The following error was observed:
>
> {code:java}
> $ solr-9.2.0/bin/solr start -f
> *** [WARN] *** Your open file limit is currently 256.
> It should be set to 65000 to avoid operational disruption.
> If you no longer wish to see this warning, set SOLR_ULIMIT_CHECKS to false
> in your profile or solr.in.sh
> *** [WARN] *** Your Max Processes Limit is currently 1392.
> It should be set to 65000 to avoid operational disruption.
> If you no longer wish to see this warning, set SOLR_ULIMIT_CHECKS to false
> in your profile or solr.in.sh
> Java 20 detected. Enabled workaround for SOLR-16463
> OpenJDK 64-Bit Server VM warning: -XX:+UseLargePages not supported in this VM
> CompileCommand: exclude
> com/github/benmanes/caffeine/cache/BoundedLocalCache.put bool exclude = true
> WARNING: A command line option has enabled the Security Manager
> WARNING: The Security Manager is deprecated and will be removed in a future
> release
> 2023-04-02 16:19:52.700 WARN (main) [] o.e.j.x.XmlConfiguration Unable to
> execute XmlConfiguration => java.security.AccessControlException: access
> denied ("java.io.FilePermission" "/" "read")
> at
> java.base/java.security.AccessControlContext.checkPermission(AccessControlContext.java:488)
> java.security.AccessControlException: access denied ("java.io.FilePermission"
> "/" "read")
> at
> java.security.AccessControlContext.checkPermission(AccessControlContext.java:488)
> ~[?:?]
> at
> java.security.AccessController.checkPermission(AccessController.java:1071)
> ~[?:?]
> at java.lang.SecurityManager.checkPermission(SecurityManager.java:411)
> ~[?:?]
> at java.lang.SecurityManager.checkRead(SecurityManager.java:742) ~[?:?]
> at sun.nio.fs.UnixPath.checkRead(UnixPath.java:788) ~[?:?]
> at
> sun.nio.fs.UnixFileSystemProvider.newDirectoryStream(UnixFileSystemProvider.java:448)
> ~[?:?]
> at sun.nio.fs.UnixPath.toRealPath(UnixPath.java:912) ~[?:?]
> at
> org.eclipse.jetty.util.resource.PathResource.<init>(PathResource.java:226)
> ~[jetty-util-10.0.13.jar:10.0.13]
> at
> org.eclipse.jetty.util.resource.Resource.newResource(Resource.java:204)
> ~[jetty-util-10.0.13.jar:10.0.13]
> at
> org.eclipse.jetty.util.resource.Resource.newResource(Resource.java:178)
> ~[jetty-util-10.0.13.jar:10.0.13]
> at
> org.eclipse.jetty.xml.XmlConfiguration.lambda$main$4(XmlConfiguration.java:1835)
> ~[jetty-xml-10.0.13.jar:10.0.13]
> at java.security.AccessController.doPrivileged(AccessController.java:571)
> ~[?:?]
> at
> org.eclipse.jetty.xml.XmlConfiguration.main(XmlConfiguration.java:1818)
> ~[jetty-xml-10.0.13.jar:10.0.13]
> at
> jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
> ~[?:?]
> at java.lang.reflect.Method.invoke(Method.java:578) ~[?:?]
> at org.eclipse.jetty.start.Main.invokeMain(Main.java:229)
> ~[start.jar:10.0.13]
> at org.eclipse.jetty.start.Main.start(Main.java:527) ~[start.jar:10.0.13]
> at org.eclipse.jetty.start.Main.main(Main.java:76) ~[start.jar:10.0.13]
> java.lang.reflect.InvocationTargetException
> at
> java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:119)
> at java.base/java.lang.reflect.Method.invoke(Method.java:578)
> at org.eclipse.jetty.start.Main.invokeMain(Main.java:229)
> at org.eclipse.jetty.start.Main.start(Main.java:527)
> at org.eclipse.jetty.start.Main.main(Main.java:76)
> Caused by: java.security.AccessControlException: access denied
> ("java.io.FilePermission" "/" "read")
> at
> java.base/java.security.AccessControlContext.checkPermission(AccessControlContext.java:488)
> at
> java.base/java.security.AccessController.checkPermission(AccessController.java:1071)
> at
> java.base/java.lang.SecurityManager.checkPermission(SecurityManager.java:411)
> at java.base/java.lang.SecurityManager.checkRead(SecurityManager.java:742)
> at java.base/sun.nio.fs.UnixPath.checkRead(UnixPath.java:788)
> at
> java.base/sun.nio.fs.UnixFileSystemProvider.newDirectoryStream(UnixFileSystemProvider.java:448)
> at java.base/sun.nio.fs.UnixPath.toRealPath(UnixPath.java:912)
> at
> org.eclipse.jetty.util.resource.PathResource.<init>(PathResource.java:226)
> at org.eclipse.jetty.util.resource.Resource.newResource(Resource.java:204)
> at org.eclipse.jetty.util.resource.Resource.newResource(Resource.java:178)
> at
> org.eclipse.jetty.xml.XmlConfiguration.lambda$main$4(XmlConfiguration.java:1835)
> at
> java.base/java.security.AccessController.doPrivileged(AccessController.java:571)
> at org.eclipse.jetty.xml.XmlConfiguration.main(XmlConfiguration.java:1818)
> at
> java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
> ... 4 more
> java.lang.reflect.InvocationTargetException
> at
> java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:119)
> at java.base/java.lang.reflect.Method.invoke(Method.java:578)
> at org.eclipse.jetty.start.Main.invokeMain(Main.java:229)
> at org.eclipse.jetty.start.Main.start(Main.java:527)
> at org.eclipse.jetty.start.Main.main(Main.java:76)
> Caused by: java.security.AccessControlException: access denied
> ("java.io.FilePermission" "/" "read")
> at
> java.base/java.security.AccessControlContext.checkPermission(AccessControlContext.java:488)
> at
> java.base/java.security.AccessController.checkPermission(AccessController.java:1071)
> at
> java.base/java.lang.SecurityManager.checkPermission(SecurityManager.java:411)
> at java.base/java.lang.SecurityManager.checkRead(SecurityManager.java:742)
> at java.base/sun.nio.fs.UnixPath.checkRead(UnixPath.java:788)
> at
> java.base/sun.nio.fs.UnixFileSystemProvider.newDirectoryStream(UnixFileSystemProvider.java:448)
> at java.base/sun.nio.fs.UnixPath.toRealPath(UnixPath.java:912)
> at
> org.eclipse.jetty.util.resource.PathResource.<init>(PathResource.java:226)
> at org.eclipse.jetty.util.resource.Resource.newResource(Resource.java:204)
> at org.eclipse.jetty.util.resource.Resource.newResource(Resource.java:178)
> at
> org.eclipse.jetty.xml.XmlConfiguration.lambda$main$4(XmlConfiguration.java:1835)
> at
> java.base/java.security.AccessController.doPrivileged(AccessController.java:571)
> at org.eclipse.jetty.xml.XmlConfiguration.main(XmlConfiguration.java:1818)
> at
> java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
> ... 4 moreUsage: java -jar $JETTY_HOME/start.jar [options] [properties]
> [configs]
> java -jar $JETTY_HOME/start.jar --help # for more information {code}
>
> Note: the warnings on open file limit and max processes limit do not seem
> related; the error still remains after {{ulimit -n 65000}} and {{{}ulimit -u
> 2088{}}}. {{ulimit -u 2088}} is macOS's hard limit.
> I have attached a full output log ({{{}solr.log{}}}) with {{_JAVA_OPTIONS}}
> set to {{{}-Djava.security.debug=access,failure,policy{}}}. I was running
> that on x86_64 macOS 13.3 (Ventura). (Note:
> [https://github.com/apache/solr/commit/f7fe594cdadeadd1e0061075a55a529793e72462]
> was applied.)
> A minimum reproducer:
> # Download and extract pre-built OpenJDK 20 binaries from
> [https://jdk.java.net/20/] (macOS / AArch64 or macOS / x64).
> # Download and extract Solr 9.2 binary release from
> [https://www.apache.org/dyn/closer.lua/solr/solr/9.2.0/solr-9.2.0.tgz?action=download]
> .
> #
> {code:java}
> export PATH="$PWD/jdk-20.jdk/Contents/Home/bin:$PATH"{code}
> #
> {code:java}
> ./solr-9.2.0/bin/solr start -f{code}
> # See error.
> This failure was observed while packaging OpenJDK 20 for Homebrew at
> [https://github.com/Homebrew/homebrew-core/pull/126319] . At the time of
> testing, Solr 9.1.1 was used. So I believe this error occurred on earlier
> versions, too.
> Thank you! Please let me know if any additional information is needed.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
