macOS 10.13.6 elasticsearch -6.4.0
kennethdeMBP:elasticsearch-6.4.0 kenneth$ ./bin/elasticsearch
Java HotSpot(TM) 64-Bit Server VM warning: Option UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in a future release.
Exception in thread "main" 2018-08-30 21:10:05,731 main ERROR No Log4j 2 configuration file found. Using default configuration (logging only errors to the console), or user programmatically provided configurations. Set system property 'log4j2.debug' to show Log4j 2 internal initialization logging. See https://logging.apache.org/log4j/2.x/manual/configuration.html for instructions on how to configure Log4j 2
SettingsException[Failed to load settings from [elasticsearch.yml]]; nested: ParsingException[Failed to parse object: expecting token of type [START_OBJECT] but found [VALUE_STRING]];
at org.elasticsearch.common.settings.Settings$Builder.loadFromStream(Settings.java:1192)
at org.elasticsearch.common.settings.Settings$Builder.loadFromPath(Settings.java:1165)
at org.elasticsearch.node.InternalSettingsPreparer.prepareEnvironment(InternalSettingsPreparer.java:100)
at org.elasticsearch.cli.EnvironmentAwareCommand.createEnv(EnvironmentAwareCommand.java:95)
at org.elasticsearch.cli.EnvironmentAwareCommand.execute(EnvironmentAwareCommand.java:86)
at org.elasticsearch.cli.Command.mainWithoutErrorHandling(Command.java:124)
at org.elasticsearch.cli.Command.main(Command.java:90)
at org.elasticsearch.bootstrap.Elasticsearch.main(Elasticsearch.java:93)
at org.elasticsearch.bootstrap.Elasticsearch.main(Elasticsearch.java:86)
Caused by: ParsingException[Failed to parse object: expecting token of type [START_OBJECT] but found [VALUE_STRING]]
at org.elasticsearch.common.xcontent.XContentParserUtils.ensureExpectedToken(XContentParserUtils.java:78)
at org.elasticsearch.common.settings.Settings.fromXContent(Settings.java:672)
at org.elasticsearch.common.settings.Settings.access$500(Settings.java:84)
at org.elasticsearch.common.settings.Settings$Builder.loadFromStream(Settings.java:1188)
... 8 more
kennethdeMBP:elasticsearch-6.4.0 kenneth$
Related
warning: ignoring JAVA_HOME=C:\Program Files\Java\jdk-11.0.15; using bundled JDK
Installing service : "elasticsearch-service-x64"
Using ES_JAVA_HOME (64-bit): "C:\Program Files\elasticsearch-8.2.0\jdk"
Exception in thread "main" java.lang.RuntimeException: starting java failed with [1]
output:
[0.150s][error][logging] Error opening log file 'logs/gc.log': Permission denied
[0.150s][error][logging] Initialization of output 'file=logs/gc.log' using options 'filecount=32,filesize=64m' failed.
error:
Could not rename log file 'logs/gc.log' to 'logs/gc.log.10' (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:114)
at org.elasticsearch.tools.launchers.JvmOption.findFinalOptions(JvmOption.java:79)
at org.elasticsearch.tools.launchers.MachineDependentHeap.determineHeapSettings(MachineDependentHeap.java:61)
at org.elasticsearch.tools.launchers.JvmOptionsParser.jvmOptions(JvmOptionsParser.java:135)
at org.elasticsearch.tools.launchers.JvmOptionsParser.main(JvmOptionsParser.java:87)
Did you try changing jvm.options and set Xms and Xms memory arguments?
Both should be the same value, and value should be below the total available system memory.
Also try changing log level in log4j.properties file to get some detailed error log, if that helps.
I am trying to get Cassandra v2.1.17 running using Java 11 (Oracle), but cannot get it to startup. I have updated all the JVM args in cassandra-env.sh to the Java 11 equivalents, but I now get the following error on startup:
ERROR 14:48:10 Exception encountered during startup
java.lang.RuntimeException: java.util.concurrent.ExecutionException: java.lang.NoSuchMethodError: sun.misc.Unsafe.monitorEnter(Ljava/lang/Object;)V
at com.google.common.base.Throwables.propagate(Throwables.java:160) ~[guava-16.0.jar:na]
...
...
...
Caused by: java.lang.NoSuchMethodError: sun.misc.Unsafe.monitorEnter(Ljava/lang/Object;)V
I have done a good bit of looking about and it seems that this class was removed in Java 9, or at least deprecated, but was still accessible using --add-modules=jdk.unsupported. Adding this to my JVM args didn't help.
Is it possible to run Cassandra 2.1.17 on Oracle Java 11? I can see that the class is still in OpenJDK 11 (https://hg.openjdk.java.net/jdk/jdk11/file/6889f13694c6/src/jdk.unsupported/share/classes/sun/misc/Unsafe.java) but I am stuck using Centos6 and cannot find an install for it.
#MeanwhileInHell, JDK 11 support for Apache Cassandra(R) was explored in the recent Cassandra 4.0 version only and I don't think it's available in very older and unsupported versions like 2.x. Please see https://cassandra.apache.org/doc/latest/cassandra/new/java11.html documentation for additional details.
https://issues.apache.org/jira/browse/CASSANDRA-9608 has details.
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.