Starting elasticsearch via command line gives weird error

cat jvm.options

## JVM configuration
################################################################
## IMPORTANT: JVM heap size
################################################################
##
## You should always set the min and max JVM heap
## size to the same value. For example, to set
## the heap to 4 GB, set:
##
## -Xms4g
## -Xmx4g
##
## See https://www.elastic.co/guide/en/elasticsearch/reference/current/heap-size.html
## for more information
##
################################################################

# Xms represents the initial size of total heap space
# Xmx represents the maximum size of total heap space

-Xms2g
-Xmx2g

################################################################
## Expert settings
################################################################
##
## All settings below this section are considered
## expert settings. Don't tamper with them unless
## you understand what you are doing
##
################################################################

## GC configuration
-XX:+UseConcMarkSweepGC
-XX:CMSInitiatingOccupancyFraction=75
-XX:+UseCMSInitiatingOccupancyOnly

## optimizations

# disable calls to System#gc
-XX:+DisableExplicitGC

# pre-touch memory pages used by the JVM during initialization
-XX:+AlwaysPreTouch

## basic

# force the server VM (remove on 32-bit client JVMs)
-server

# explicitly set the stack size (reduce to 320k on 32-bit client JVMs)
-Xss1m

# set to headless, just in case
-Djava.awt.headless=true

# ensure UTF-8 encoding by default (e.g. filenames)
-Dfile.encoding=UTF-8

# use our provided JNA always versus the system one
-Djna.nosys=true

# use old-style file permissions on JDK9
-Djdk.io.permissionsUseCanonicalPath=true

# flags to configure Netty
-Dio.netty.noUnsafe=true
-Dio.netty.noKeySetOptimization=true
-Dio.netty.recycler.maxCapacityPerThread=0

# log4j 2
-Dlog4j.shutdownHookEnabled=false
-Dlog4j2.disable.jmx=true
-Dlog4j.skipJansi=true

## heap dumps

# generate a heap dump when an allocation from the Java heap fails
# heap dumps are created in the working directory of the JVM
-XX:+HeapDumpOnOutOfMemoryError

# specify an alternative path for heap dumps
# ensure the directory exists and has sufficient space
#-XX:HeapDumpPath=${heap.dump.path}

## GC logging

#-XX:+PrintGCDetails
#-XX:+PrintGCTimeStamps
#-XX:+PrintGCDateStamps
#-XX:+PrintClassHistogram
#-XX:+PrintTenuringDistribution
#-XX:+PrintGCApplicationStoppedTime

# log GC status to a file with time stamps
# ensure the directory exists
#-Xloggc:${loggc}

# Elasticsearch 5.0.0 will throw an exception on unquoted field names in JSON.
# If documents were already indexed with unquoted fields in a previous version
# of Elasticsearch, some operations may throw errors.
#
# WARNING: This option will be removed in Elasticsearch 6.0.0 and is provided
# only for migration purposes.
#-Delasticsearch.json.allow_unquoted_field_names=true

This is weird.
Can you copy again the exact command line you ran last time?

Ha sorry. Got it. It was:

/usr/share/elasticsearch/v5/bin/elasticsearch -Ecluster.name=test -Enode.name=test-client-cluster-1 -Ehttp.port=19270 -Epath.conf=/opt/sources/wpCloud/node-sql-service/static/etc/elasticsearchv5 -Epath.logs=/var/log/elasticsearch/clients/test -Epath.data=/var/lib/elasticsearch/clients/test -Etransport.tcp.port=19370-19470 -Epidfile=/var/run/elasticsearch/clients/test/test.pid -Epath.repo=/.snapshots/test -Enetwork.host=0.0.0.0

I need to check locally but it seems that your -Epath.conf is not taken into account for whatever reason.

Can you try to run with:

ES_JVM_OPTIONS="/opt/sources/wpCloud/node-sql-service/static/etc/elasticsearchv5/jvm.options" /usr/share/elasticsearch/v5/bin/elasticsearch -Ecluster.name=test -Enode.name=test-client-cluster-1 -Ehttp.port=19270 -Epath.conf=/opt/sources/wpCloud/node-sql-service/static/etc/elasticsearchv5 -Epath.logs=/var/log/elasticsearch/clients/test -Epath.data=/var/lib/elasticsearch/clients/test -Etransport.tcp.port=19370-19470 -Epidfile=/var/run/elasticsearch/clients/test/test.pid -Epath.repo=/.snapshots/test -Enetwork.host=0.0.0.0

Actually we read by default jvm.options only in the installation dir/config (I suppose you moved it) or from /etc/elasticsearch/. See: https://github.com/elastic/elasticsearch/blob/5.2/distribution/src/main/resources/bin/elasticsearch#L113-L121

LMK

I don't think that it was not taken in consideration since when I was sharing the v2 and v5 configs if it wouldn't be taken in consideration it would'nt have complained about logger.yml as soon as I moved to separate config folder that error did dissapear.

However I have started with the ES_JVM_OPTIONS I see the elasticsearch starting and listening on port 19270 but when I try to run a curl on it I get the following error:

{"error":{"root_cause":[{"type":"illegal_argument_exception","reason":"No endpoint or operation is available at [node]"}],"type":"illegal_argument_exception","reason":"No endpoint or operation is available at [node]"},"status":400}core@client-cluster-1:~$ ```

    netstat -ntl | grep 19[2,3]70
    tcp6       0      0 :::19270                :::*                    LISTEN     
    tcp6       0      0 :::19370                :::*                    LISTEN

Ah nevermind I ate an s from nodes

This seam to be fixed now. Thanks for your help.

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.