I have a problem when starting my server glassfish. When I start it loads in about 1 minute and then immediately sends the error message quoted below.
Glassfish domain config:
<java-config debug-options="-Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=9009" system-classpath="" classpath-suffix="">
<jvm-options>-Djava.awt.headless=true</jvm-options>
<jvm-options>-XX:+AggressiveOpts</jvm-options>
<jvm-options>-Djava.security.policy=${com.sun.aas.instanceRoot}/config/server.policy</jvm-options>
<jvm-options>-Xmn1500m</jvm-options>
<jvm-options>-XX:+UseLargePages</jvm-options>
<jvm-options>-Dfelix.fileinstall.disableConfigSave=false</jvm-options>
<jvm-options>-Dosgi.shell.telnet.maxconn=1</jvm-options>
<jvm-options>-Dfelix.fileinstall.poll=5000</jvm-options>
<jvm-options>-XX:NewRatio=2</jvm-options>
<jvm-options>-Djava.endorsed.dirs=${com.sun.aas.installRoot}/modules/endorsed${path.separator}${com.sun.aas.installRoot}/lib/endorsed</jvm-options>
<jvm-options>-Dosgi.shell.telnet.port=6666</jvm-options>
<jvm-options>-Dcom.sun.enterprise.config.config_environment_factory_class=com.sun.enterprise.config.serverbeans.AppserverConfigEnvironmentFactory</jvm-options>
<jvm-options>-Djava.ext.dirs=${com.sun.aas.javaRoot}/lib/ext${path.separator}${com.sun.aas.javaRoot}/jre/lib/ext${path.separator}${com.sun.aas.instanceRoot}/lib/ext</jvm-options>
<jvm-options>-XX:+UseParallelOldGC</jvm-options>
<jvm-options>-XX:PermSize=2048m</jvm-options>
<jvm-options>-Dgosh.args=--nointeractive</jvm-options>
<jvm-options>-Dwebconsole.type=properties</jvm-options>
<jvm-options>-Djava.rmi.server.hostname=localhost</jvm-options>
<jvm-options>-Dwebconsole.jms.url=tcp://localhost:61616</jvm-options>
<jvm-options>-Djavax.management.builder.initial=com.sun.enterprise.v3.admin.AppServerMBeanServerBuilder</jvm-options>
<jvm-options>-Dcom.sun.enterprise.security.httpsOutboundKeyAlias=s1as</jvm-options>
<jvm-options>-XX:MaxPermSize=4096m</jvm-options>
<jvm-options>-XX:LargePageSizeInBytes=2048k</jvm-options>
<jvm-options>-XX:+UnlockDiagnosticVMOptions</jvm-options>
<jvm-options>-XX:ParallelGCThreads=16</jvm-options>
<jvm-options>-Dwebconsole.jmx.url=service:jmx:rmi:///jndi/rmi://localhost:1099/jmxrmi</jvm-options>
<jvm-options>-Dfelix.fileinstall.bundles.startTransient=true</jvm-options>
<jvm-options>-Dfelix.fileinstall.bundles.new.start=true</jvm-options>
<jvm-options>-Dfelix.fileinstall.dir=${com.sun.aas.installRoot}/modules/autostart/</jvm-options>
<jvm-options>-Djava.security.auth.login.config=${com.sun.aas.instanceRoot}/config/login.conf</jvm-options>
<jvm-options>-Dosgi.shell.telnet.ip=127.0.0.1</jvm-options>
<jvm-options>-Dfelix.fileinstall.log.level=2</jvm-options>
<jvm-options>-Djavax.net.ssl.keyStore=${com.sun.aas.instanceRoot}/config/keystore.jks</jvm-options>
<jvm-options>-server</jvm-options>
<jvm-options>-Djdbc.drivers=org.apache.derby.jdbc.ClientDriver</jvm-options>
<jvm-options>-DAllowMediatedWriteInDefaultFetchGroup=true</jvm-options>
<jvm-options>-Djavax.net.ssl.trustStore=${com.sun.aas.instanceRoot}/config/cacerts.jks</jvm-options>
<jvm-options>-Dcom.sun.enterprise.server.ss.ASQuickStartup=false</jvm-options>
<jvm-options>-Xms2048m</jvm-options>
<jvm-options>-DANTLR_USE_DIRECT_CLASS_LOADING=true</jvm-options>
<jvm-options>-Xmx5020m</jvm-options>
<jvm-options>-XX:+UseTLAB</jvm-options>
<jvm-options>-XX:+UseParallelGC</jvm-options>
</java-config>
Error description:
Waiting for domain1 to start ..................................Error starting domain domain1.
The server exited prematurely with exit code 0.
Before it died, it produced the following output:
Java HotSpot(TM) 64-Bit Server VM warning: Failed to reserve shared memory (errno = 22).
Java HotSpot(TM) 64-Bit Server VM warning: Failed to reserve shared memory (errno = 22).
Launching GlassFish on Felix platform
Exception: java.lang.NullPointerException thrown from the UncaughtExceptionHandler in thread "Grizzly-kernel-thread(1)"
Exception: java.lang.NullPointerException thrown from the UncaughtExceptionHandler in thread "Grizzly-kernel-thread(1)"
Command start-domain failed.
If someone know what i can do to fix this problem will help me a lot.
Thanks!
This problem occurs when you are using -XX:+UseLargePages and no more HugePages are available or they are not accessible for the current user.
You can see if HugePages are available if you run: cat /proc/meminfo (on *nix)
Try removing the JVM option and see if it helps. In the debian wiki you can get some detailed information about HugePages and how they are used.
Related
After running bin\elasticsearch.bat
Exception in thread "main" java.lang.RuntimeException: starting java failed with [1]
output:
error:
Unrecognized VM option 'UseConcMarkSweepGC'
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.
at org.elasticsearch.server.cli.JvmOption.flagsFinal(JvmOption.java:113)
at org.elasticsearch.server.cli.JvmOption.findFinalOptions(JvmOption.java:80)
at org.elasticsearch.server.cli.MachineDependentHeap.determineHeapSettings(MachineDependentHeap.java:59)
at org.elasticsearch.server.cli.JvmOptionsParser.jvmOptions(JvmOptionsParser.java:132)
at org.elasticsearch.server.cli.JvmOptionsParser.determineJvmOptions(JvmOptionsParser.java:90)
at org.elasticsearch.server.cli.ServerProcess.createProcess(ServerProcess.java:211)
at org.elasticsearch.server.cli.ServerProcess.start(ServerProcess.java:106)
at org.elasticsearch.server.cli.ServerProcess.start(ServerProcess.java:89)
at org.elasticsearch.server.cli.ServerCli.startServer(ServerCli.java:213)
at org.elasticsearch.server.cli.ServerCli.execute(ServerCli.java:90)
at org.elasticsearch.common.cli.EnvironmentAwareCommand.execute(EnvironmentAwareCommand.java:54)
at org.elasticsearch.cli.Command.mainWithoutErrorHandling(Command.java:85)
at org.elasticsearch.cli.Command.main(Command.java:50)
at org.elasticsearch.launcher.CliToolLauncher.main(CliToolLauncher.java:64)
I had the same issue trying to run Elasticsearch 8.3.3 after stopping ES 6.2.1.
I was able to run version 8.3 by deleting 2 environment variables which pointed to the old ES folder (6.2) :
ES_HOME
ES_PATH_CONF
Probably updating them to the new Elasticsearch home would work as well.
I have problems with running Elastic Search on my ubuntu 20.04 server (I can do it locally). When I run ./bin/elasticsearch in terminal I get lines below
Exception in thread "main" java.lang.RuntimeException: starting java failed with [1]
output:
[0.000s][error][logging] Error opening log file 'logs/gc.log': Permission denied
[0.001s][error][logging] Initialization of output 'file=logs/gc.log' using options 'filecount=32,filesize=64m' failed.
error:
OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in a future release.
Could not rename log file 'logs/gc.log' to 'logs/gc.log.05' (Permission denied).
Invalid -Xlog option '-Xlog:gc*,gc+age=trace,safepoint:file=logs/gc.log:utctime,pid,tags:filecount=32,filesize=64m', see error log for details.
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.
at org.elasticsearch.tools.launchers.JvmOption.flagsFinal(JvmOption.java:119)
at org.elasticsearch.tools.launchers.JvmOption.findFinalOptions(JvmOption.java:81)
at org.elasticsearch.tools.launchers.JvmErgonomics.choose(JvmErgonomics.java:38)
at org.elasticsearch.tools.launchers.JvmOptionsParser.jvmOptions(JvmOptionsParser.java:135)
at org.elasticsearch.tools.launchers.JvmOptionsParser.main(JvmOptionsParser.java:86)
What I tried: sudo chmod -R +w /home/ubuntu/data/stepa/elasticsearch-7.16.2/logs/. It didn't help.
I didn't succeed to find answer on elastic search forum.
Thank you for any help.
Finally, I found the solution. Log lines mean problems with rights. Current user has to be an owner of directory. In my case owner of /home/ubuntu/data/stepa/elasticsearch-7.16.2/logs/ was root. I changed it using this command sudo chown username:group /home/ubuntu/data/stepa/elasticsearch-7.16.2/logs
("ubuntu: " in my case because group is default and username is ubuntu)
Thanks to ilvar for clues.
im getting an error while running elasticsearch on kubernetes. I dont believe this is a memory allocation issue but i dont know. Trying to set it up with discovery - not a single node.
here is my kubernetes config for elasticsearch - https://hastebin.com/ohiyivinit.bash
Here is my error on startup from kubectl logs
Exception in thread "main" java.lang.RuntimeException: starting java failed with [137]
output:
error:
OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in a future release.
at org.elasticsearch.tools.launchers.JvmErgonomics.flagsFinal(JvmErgonomics.java:111)
at org.elasticsearch.tools.launchers.JvmErgonomics.finalJvmOptions(JvmErgonomics.java:79)
at org.elasticsearch.tools.launchers.JvmErgonomics.choose(JvmErgonomics.java:57)
at org.elasticsearch.tools.launchers.JvmOptionsParser.main(JvmOptionsParser.java:89)
EDIT: my error was that the requested memory was the same as the max memory in limits
The error code strongly suggests this is a memory issue.
Since you're using GKE, if Stackdriver is enabled, you can use the following advanced filter to confirm if this is an OOM kill:
resource.type="container"
resource.labels.cluster_name="YOUR_CLUSTER"
resource.labels.namespace_id="NAMESPACE"
resource.labels.project_id="PROJECT_ID"
resource.labels.zone:"ZONE"
resource.labels.container_name="CONTAINER_NAME" # Container name, not pod name
resource.labels.pod_id:"POD_NAME-" # Notice that is not the full pod ID
"OOM"
If you find out this is an OOM issue, you can set requests and limits to your deployment to ensure the resources are enough to run your application.
enter image description hereTry to run command prompt run as administartor
When I'm importing following a project from GitHub, I am getting 2 error's
Project
https://github.com/davidanthonymalone/Beer-Finder
Error
Error: Unable to start the daemon process.
This problem might be caused by incorrect configuration of the daemon.
For example, an unrecognized jvm option is used.
Please refer to the user guide chapter on the daemon at https://docs.gradle.org/2.14.1/userguide/gradle_daemon.html
Please read the following process output to find out more:
Error occurred during initialization of VM
Could not reserve enough space for 2097152KB object heap
Java HotSpot(TM) Client VM warning: ignoring option MaxPermSize=512m; support was removed in 8.0
I've got a weird problem regarding the NEXUS OSS. We cannot push onto it with maven anymore. Always getting the error on the push "
Failed to deploy artifact could not transfer artifact
At first I was getting the following error in the nexus oss log.:
2017-07-18 09:22:16,226+0200 WARN [Timer-0] *SYSTEM java.util.prefs - Could not lock User prefs. Unix error code 2.
2017-07-18 09:22:16,226+0200 WARN [Timer-0] *SYSTEM java.util.prefs - Couldn't flush user prefs: java.util.prefs.BackingStoreException: Couldn't get file lock.
I googled and found a solution here.:
https://support.sonatype.com/hc/en-us/articles/213464868-Nexus-startup-fails-with-Could-not-lock-User-prefs-Couldn-t-flush-user-prefs-Couldn-t-get-file-lock- I modified it to work with Version 3.4. so I had to add the Java line in
/opt/nexus/bin/nexus.vmoptions
this line is added
-Djava.util.prefs.userRoot=/home/nexus/.java
I also created the directory
/home/nexus/.java/.userPrefs
I assigned the service user nexus and the group nexus as owner and also edited for testing purposes the rights to 777.
After another restart, the error is still present at the client for pushing, but I do not see any error in the logs anymore. The lock User Error is now gone.
Does anybody have an idea what to do?
Nexus OSS Version.: 3.4.0-02
Debian.: 8
Java.:
java version "1.8.0_102" Java(TM) SE Runtime Environment (build
1.8.0_102-b14) Java HotSpot(TM) 64-Bit Server VM (build 25.102-b14, mixed mode)
I managed to get rid of this message by editing my
/usr/local/nexus/bin/nexus.vmoptions
and appended
-Djava.util.prefs.userRoot=/home/nexus/.java
The directory must exist and the user must also be nexus.
it worked for me....
The following resolution did the trick.
The Nexus was running behind a NGINX Reverseproxy, which didn't allow "PUT" operations. Only GET and POST where allowed.