[ https://issues.apache.org/jira/browse/SOLR-16733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17707726#comment-17707726 ]
Ruoyu Zhong commented on SOLR-16733: ------------------------------------ Thanks [~elyograg] for your response. > Installed Oracle JDK 20 onto Ubuntu 20.04 Server using Oracle's x64 .deb > package. I've just tried this in a Ubuntu 22.04 Docker (with a non-root user) with OpenJDK 20. It seems that this error is indeed _not_ reproducible on Linux, and thus macOS-specific. > Note that you should NOT run Solr as root, which is the only reason you would > need the -f flag. Perhaps you was referring to the {{-force}} flag: {code:java} $ sudo solr start Password: *** [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 WARNING: Starting Solr as the root user is a security risk and not considered best practice. Exiting. Please consult the Reference Guide. To override this check, start with argument '-force' {code} I was using the {{-f}} flag to start Solr in foreground so we could immediately tell from the console what is going on. {code:java} $ solr start --help ERROR: --help is not supported by this script Usage: solr start [-f] [-c] [-h hostname] [-p port] [-d directory] [-z zkHost] [-m memory] [-e example] [-s solr.solr.home] [-t solr.data.home] [-a "additional-options"] [-V] -f Start Solr in foreground; default starts Solr in the background and sends stdout / stderr to solr-PORT-console.log {code} If Solr is started without the {{-f}} flag, the error is similar: {code:java} $ solr-9.2.0/bin/solr start --help $ SOLR_LOGS_DIR=/tmp/solr solr start &>/dev/null & [1] 8930 $ head -n10 /tmp/solr/solr-8983-console.log 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 ERROR StatusConsoleListener Could not create plugin of type class org.apache.logging.log4j.core.appender.RollingRandomAccessFileAppender for element RollingRandomAccessFile: java.security.AccessControlException: access denied ("java.io.FilePermission" "/private/tmp/solr" "read") java.security.AccessControlException: access denied ("java.io.FilePermission" "/private/tmp/solr" "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) $ echo $JAVA_HOME /tmp/jdk-20.jdk/Contents/Home $ which java /tmp/jdk-20.jdk/Contents/Home/bin/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) $ sw_vers ProductName: macOS ProductVersion: 13.3 BuildVersion: 22E252{code} For this run (without the {{-f}} flag), I did notice that an "access denied" error occurred on the temporary {{SOLR_LOGS_DIR}} that I set: {code:java} $ grep denied /tmp/solr/solr-8983-console.log ERROR StatusConsoleListener Could not create plugin of type class org.apache.logging.log4j.core.appender.RollingRandomAccessFileAppender for element RollingRandomAccessFile: java.security.AccessControlException: access denied ("java.io.FilePermission" "/private/tmp/solr" "read") java.security.AccessControlException: access denied ("java.io.FilePermission" "/private/tmp/solr" "read") ERROR StatusConsoleListener Could not create plugin of type class org.apache.logging.log4j.core.appender.RollingRandomAccessFileAppender for element RollingRandomAccessFile: java.security.AccessControlException: access denied ("java.io.FilePermission" "/private/tmp/solr" "read") java.security.AccessControlException: access denied ("java.io.FilePermission" "/private/tmp/solr" "read") Caused by: java.security.AccessControlException: access denied ("java.io.FilePermission" "/" "read") Caused by: java.security.AccessControlException: access denied ("java.io.FilePermission" "/" "read") {code} Again I attach the full logs in SOLR_LOGS_DIR for your reference. They are: {{solr-8983-console.log}} and {{{}solr_gc.log{}}}. > 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 > Security Level: Public(Default Security Level. Issues are Public) > 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}) > 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 > Priority: Minor > Attachments: solr-8983-console.log, solr.log, solr_gc.log > > > 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