sysctl: permission denied on key 'vm.max_map_count' - OpenVZ Elasticsearch 0.90.9 compatibility issue #4978

Closed
bline79 opened this Issue Jan 31, 2014 · 80 comments

Comments

Projects
None yet
@bline79

bline79 commented Jan 31, 2014

Hello,

Elasticsearch 0.90.9 and higher do not work with openvz (tested with debian wheezy i386) with the following error showing on startup:

Starting ElasticSearch Server:sysctl: permission denied on key 'vm.max_map_count'

@spinscale

This comment has been minimized.

Show comment
Hide comment
@spinscale

spinscale Feb 3, 2014

Member

Hey,

can you please check, if the process started anyway? It should have been. The error is just a permission problem due to your VM, but should not prevent elasticsearch from starting usually.

Member

spinscale commented Feb 3, 2014

Hey,

can you please check, if the process started anyway? It should have been. The error is just a permission problem due to your VM, but should not prevent elasticsearch from starting usually.

@spinscale spinscale self-assigned this Feb 3, 2014

@dmikhaylov

This comment has been minimized.

Show comment
Hide comment
@dmikhaylov

dmikhaylov Feb 24, 2014

I've got the same issue, and on my VM it's not starting.

I've got the same issue, and on my VM it's not starting.

@spinscale

This comment has been minimized.

Show comment
Hide comment
@spinscale

spinscale Feb 24, 2014

Member

can you add set -x to the elasticsearch init script and paste the output from /etc/init.d/elasticsearch start here?

Member

spinscale commented Feb 24, 2014

can you add set -x to the elasticsearch init script and paste the output from /etc/init.d/elasticsearch start here?

@dmikhaylov

This comment has been minimized.

Show comment
Hide comment
@dmikhaylov

dmikhaylov Feb 24, 2014

do you mean /etc/init.d/elasticsearch start set -x?

do you mean /etc/init.d/elasticsearch start set -x?

@spinscale

This comment has been minimized.

Show comment
Hide comment
@spinscale

spinscale Feb 24, 2014

Member

sorry for not being clear. You can do the following: Open /etc/init.d/elasticsearch in your favourite editor and change the current setup

#!/bin/sh
#

to

#!/bin/sh
set -x
#

Then run /etc/init.d/elasticsearch start and copy paste all that output into this ticket. You might want to comment out or remove that line again after that, so you do not get his verbose output all the time.

Thanks a lot for helping!

Member

spinscale commented Feb 24, 2014

sorry for not being clear. You can do the following: Open /etc/init.d/elasticsearch in your favourite editor and change the current setup

#!/bin/sh
#

to

#!/bin/sh
set -x
#

Then run /etc/init.d/elasticsearch start and copy paste all that output into this ticket. You might want to comment out or remove that line again after that, so you do not get his verbose output all the time.

Thanks a lot for helping!

@dmikhaylov

This comment has been minimized.

Show comment
Hide comment
@dmikhaylov

dmikhaylov Feb 24, 2014

  • PATH=/bin:/usr/bin:/sbin:/usr/sbin
  • NAME=elasticsearch
  • DESC='ElasticSearch Server'
  • DEFAULT=/etc/default/elasticsearch
    ++ id -u
  • '[' 0 -ne 0 ']'
  • . /lib/lsb/init-functions
    ++ FANCYTTY=
    ++ '[' -e /etc/lsb-base-logging.sh ']'
    ++ . /etc/lsb-base-logging.sh
    +++ LOG_DAEMON_MSG=
  • '[' -r /etc/default/rcS ']'
  • . /etc/default/rcS
    ++ TMPTIME=0
    ++ SULOGIN=no
    ++ DELAYLOGIN=no
    ++ UTC=yes
    ++ VERBOSE=no
    ++ FSCKFIX=no
  • ES_USER=elasticsearch
  • ES_GROUP=elasticsearch
  • JDK_DIRS='/usr/lib/jvm/java-7-oracle /usr/lib/jvm/java-7-openjdk /usr/lib/jvm/java-7-openjdk-amd64/ /usr/lib/jvm/java-7-openjdk-armhf /usr/lib/jvm/java-7-openjdk-i386/ /usr/lib/jvm/java-6-sun /usr/lib/jvm/java-6-openjdk /usr/lib/jvm/java-6-openjdk-amd64 /usr/lib/jvm/java-6-openjdk-armhf /usr/lib/jvm/java-6-openjdk-i386 /usr/lib/jvm/default-java'
  • for jdir in '$JDK_DIRS'
  • '[' -r /usr/lib/jvm/java-7-oracle/bin/java -a -z '' ']'
  • for jdir in '$JDK_DIRS'
  • '[' -r /usr/lib/jvm/java-7-openjdk/bin/java -a -z '' ']'
  • for jdir in '$JDK_DIRS'
  • '[' -r /usr/lib/jvm/java-7-openjdk-amd64//bin/java -a -z '' ']'
  • for jdir in '$JDK_DIRS'
  • '[' -r /usr/lib/jvm/java-7-openjdk-armhf/bin/java -a -z '' ']'
  • for jdir in '$JDK_DIRS'
  • '[' -r /usr/lib/jvm/java-7-openjdk-i386//bin/java -a -z '' ']'
  • for jdir in '$JDK_DIRS'
  • '[' -r /usr/lib/jvm/java-6-sun/bin/java -a -z '' ']'
  • for jdir in '$JDK_DIRS'
  • '[' -r /usr/lib/jvm/java-6-openjdk/bin/java -a -z '' ']'
  • JAVA_HOME=/usr/lib/jvm/java-6-openjdk
  • for jdir in '$JDK_DIRS'
  • '[' -r /usr/lib/jvm/java-6-openjdk-amd64/bin/java -a -z /usr/lib/jvm/java-6-openjdk ']'
  • for jdir in '$JDK_DIRS'
  • '[' -r /usr/lib/jvm/java-6-openjdk-armhf/bin/java -a -z /usr/lib/jvm/java-6-openjdk ']'
  • for jdir in '$JDK_DIRS'
  • '[' -r /usr/lib/jvm/java-6-openjdk-i386/bin/java -a -z /usr/lib/jvm/java-6-openjdk ']'
  • for jdir in '$JDK_DIRS'
  • '[' -r /usr/lib/jvm/default-java/bin/java -a -z /usr/lib/jvm/java-6-openjdk ']'
  • export JAVA_HOME
  • ES_HOME=/usr/share/elasticsearch
  • MAX_OPEN_FILES=65535
  • LOG_DIR=/var/log/elasticsearch
  • DATA_DIR=/var/lib/elasticsearch
  • WORK_DIR=/tmp/elasticsearch
  • CONF_DIR=/etc/elasticsearch
  • CONF_FILE=/etc/elasticsearch/elasticsearch.yml
  • MAX_MAP_COUNT=65535
  • '[' -f /etc/default/elasticsearch ']'
  • . /etc/default/elasticsearch
  • PID_FILE=/var/run/elasticsearch.pid
  • DAEMON=/usr/share/elasticsearch/bin/elasticsearch
  • DAEMON_OPTS='-p /var/run/elasticsearch.pid -Des.default.config=/etc/elasticsearch/elasticsearch.yml -Des.default.path.home=/usr/share/elasticsearch -Des.default.path.logs=/var/log/elasticsearch -Des.default.path.data=/var/lib/elasticsearch -Des.default.path.work=/tmp/elasticsearch -Des.default.path.conf=/etc/elasticsearch'
  • export ES_HEAP_SIZE
  • export ES_HEAP_NEWSIZE
  • export ES_DIRECT_SIZE
  • export ES_JAVA_OPTS
  • test -x /usr/share/elasticsearch/bin/elasticsearch
  • case "$1" in
  • checkJava
  • '[' -x /usr/lib/jvm/java-6-openjdk/bin/java ']'
  • JAVA=/usr/lib/jvm/java-6-openjdk/bin/java
  • '[' '!' -x /usr/lib/jvm/java-6-openjdk/bin/java ']'
  • '[' -n '' -a -z '' ']'
  • log_daemon_msg 'Starting ElasticSearch Server'
  • '[' -z 'Starting ElasticSearch Server' ']'
  • log_use_fancy_output
  • TPUT=/usr/bin/tput
  • EXPR=/usr/bin/expr
  • '[' -t 1 ']'
  • '[' xxterm '!=' x ']'
  • '[' xxterm '!=' xdumb ']'
  • '[' -x /usr/bin/tput ']'
  • '[' -x /usr/bin/expr ']'
  • /usr/bin/tput hpa 60
  • /usr/bin/tput setaf 1
  • '[' -z ']'
  • FANCYTTY=1
  • case "$FANCYTTY" in
  • true
  • /usr/bin/tput xenl
    ++ /usr/bin/tput cols
  • COLS=80
  • '[' 80 ']'
  • '[' 80 -gt 6 ']'
    ++ /usr/bin/expr 80 - 7
  • COL=73
  • log_use_plymouth
  • '[' n = y ']'
  • plymouth --ping
  • printf ' * Starting ElasticSearch Server '
    • Starting ElasticSearch Server ++ /usr/bin/expr 80 - 1
  • /usr/bin/tput hpa 79
    + printf ' '
    ++ pidofproc -p /var/run/elasticsearch.pid elasticsearch
    ++ local pidfile line i pids= status specified pid
    ++ pidfile=
    ++ specified=
    ++ OPTIND=1
    ++ getopts p: opt
    ++ case "$opt" in
    ++ pidfile=/var/run/elasticsearch.pid
    ++ specified=1
    ++ getopts p: opt
    ++ shift 2
    ++ base=elasticsearch
    ++ '[' '!' 1 ']'
    ++ '[' -n /var/run/elasticsearch.pid -a -r /var/run/elasticsearch.pid ']'
    ++ read pid
    ++ '[' -n 16987 ']'
    +++ kill -0 16987
    ++ ps 16987
    ++ return 1
  • pid=
  • '[' -n '' ']'
  • mkdir -p /var/log/elasticsearch /var/lib/elasticsearch /tmp/elasticsearch
  • chown elasticsearch:elasticsearch /var/log/elasticsearch /var/lib/elasticsearch /tmp/elasticsearch
  • touch /var/run/elasticsearch.pid
  • chown elasticsearch:elasticsearch /var/run/elasticsearch.pid
  • '[' -n 65535 ']'
  • ulimit -n 65535
  • '[' -n '' ']'
  • '[' -n 65535 ']'
  • sysctl -q -w vm.max_map_count=65535
    error: permission denied on key 'vm.max_map_count'
  • start-stop-daemon --start -b --user elasticsearch -c elasticsearch --pidfile /var/run/elasticsearch.pid --exec /usr/share/elasticsearch/bin/elasticsearch -- -p /var/run/elasticsearch.pid -Des.default.config=/etc/elasticsearch/elasticsearch.yml -Des.default.path.home=/usr/share/elasticsearch -Des.default.path.logs=/var/log/elasticsearch -Des.default.path.data=/var/lib/elasticsearch -Des.default.path.work=/tmp/elasticsearch -Des.default.path.conf=/etc/elasticsearch
  • log_end_msg 0
  • '[' -z 0 ']'
  • '[' 73 ']'
  • '[' -x /usr/bin/tput ']'
  • log_use_plymouth
  • '[' n = y ']'
  • plymouth --ping
  • printf '\r'
  • /usr/bin/tput hpa 73
    + '[' 0 -eq 0 ']'
  • echo '[ OK ]'
    [ OK ]
  • return 0
  • exit 0
  • PATH=/bin:/usr/bin:/sbin:/usr/sbin
  • NAME=elasticsearch
  • DESC='ElasticSearch Server'
  • DEFAULT=/etc/default/elasticsearch
    ++ id -u
  • '[' 0 -ne 0 ']'
  • . /lib/lsb/init-functions
    ++ FANCYTTY=
    ++ '[' -e /etc/lsb-base-logging.sh ']'
    ++ . /etc/lsb-base-logging.sh
    +++ LOG_DAEMON_MSG=
  • '[' -r /etc/default/rcS ']'
  • . /etc/default/rcS
    ++ TMPTIME=0
    ++ SULOGIN=no
    ++ DELAYLOGIN=no
    ++ UTC=yes
    ++ VERBOSE=no
    ++ FSCKFIX=no
  • ES_USER=elasticsearch
  • ES_GROUP=elasticsearch
  • JDK_DIRS='/usr/lib/jvm/java-7-oracle /usr/lib/jvm/java-7-openjdk /usr/lib/jvm/java-7-openjdk-amd64/ /usr/lib/jvm/java-7-openjdk-armhf /usr/lib/jvm/java-7-openjdk-i386/ /usr/lib/jvm/java-6-sun /usr/lib/jvm/java-6-openjdk /usr/lib/jvm/java-6-openjdk-amd64 /usr/lib/jvm/java-6-openjdk-armhf /usr/lib/jvm/java-6-openjdk-i386 /usr/lib/jvm/default-java'
  • for jdir in '$JDK_DIRS'
  • '[' -r /usr/lib/jvm/java-7-oracle/bin/java -a -z '' ']'
  • for jdir in '$JDK_DIRS'
  • '[' -r /usr/lib/jvm/java-7-openjdk/bin/java -a -z '' ']'
  • for jdir in '$JDK_DIRS'
  • '[' -r /usr/lib/jvm/java-7-openjdk-amd64//bin/java -a -z '' ']'
  • for jdir in '$JDK_DIRS'
  • '[' -r /usr/lib/jvm/java-7-openjdk-armhf/bin/java -a -z '' ']'
  • for jdir in '$JDK_DIRS'
  • '[' -r /usr/lib/jvm/java-7-openjdk-i386//bin/java -a -z '' ']'
  • for jdir in '$JDK_DIRS'
  • '[' -r /usr/lib/jvm/java-6-sun/bin/java -a -z '' ']'
  • for jdir in '$JDK_DIRS'
  • '[' -r /usr/lib/jvm/java-6-openjdk/bin/java -a -z '' ']'
  • JAVA_HOME=/usr/lib/jvm/java-6-openjdk
  • for jdir in '$JDK_DIRS'
  • '[' -r /usr/lib/jvm/java-6-openjdk-amd64/bin/java -a -z /usr/lib/jvm/java-6-openjdk ']'
  • for jdir in '$JDK_DIRS'
  • '[' -r /usr/lib/jvm/java-6-openjdk-armhf/bin/java -a -z /usr/lib/jvm/java-6-openjdk ']'
  • for jdir in '$JDK_DIRS'
  • '[' -r /usr/lib/jvm/java-6-openjdk-i386/bin/java -a -z /usr/lib/jvm/java-6-openjdk ']'
  • for jdir in '$JDK_DIRS'
  • '[' -r /usr/lib/jvm/default-java/bin/java -a -z /usr/lib/jvm/java-6-openjdk ']'
  • export JAVA_HOME
  • ES_HOME=/usr/share/elasticsearch
  • MAX_OPEN_FILES=65535
  • LOG_DIR=/var/log/elasticsearch
  • DATA_DIR=/var/lib/elasticsearch
  • WORK_DIR=/tmp/elasticsearch
  • CONF_DIR=/etc/elasticsearch
  • CONF_FILE=/etc/elasticsearch/elasticsearch.yml
  • MAX_MAP_COUNT=65535
  • '[' -f /etc/default/elasticsearch ']'
  • . /etc/default/elasticsearch
  • PID_FILE=/var/run/elasticsearch.pid
  • DAEMON=/usr/share/elasticsearch/bin/elasticsearch
  • DAEMON_OPTS='-p /var/run/elasticsearch.pid -Des.default.config=/etc/elasticsearch/elasticsearch.yml -Des.default.path.home=/usr/share/elasticsearch -Des.default.path.logs=/var/log/elasticsearch -Des.default.path.data=/var/lib/elasticsearch -Des.default.path.work=/tmp/elasticsearch -Des.default.path.conf=/etc/elasticsearch'
  • export ES_HEAP_SIZE
  • export ES_HEAP_NEWSIZE
  • export ES_DIRECT_SIZE
  • export ES_JAVA_OPTS
  • test -x /usr/share/elasticsearch/bin/elasticsearch
  • case "$1" in
  • checkJava
  • '[' -x /usr/lib/jvm/java-6-openjdk/bin/java ']'
  • JAVA=/usr/lib/jvm/java-6-openjdk/bin/java
  • '[' '!' -x /usr/lib/jvm/java-6-openjdk/bin/java ']'
  • '[' -n '' -a -z '' ']'
  • log_daemon_msg 'Starting ElasticSearch Server'
  • '[' -z 'Starting ElasticSearch Server' ']'
  • log_use_fancy_output
  • TPUT=/usr/bin/tput
  • EXPR=/usr/bin/expr
  • '[' -t 1 ']'
  • '[' xxterm '!=' x ']'
  • '[' xxterm '!=' xdumb ']'
  • '[' -x /usr/bin/tput ']'
  • '[' -x /usr/bin/expr ']'
  • /usr/bin/tput hpa 60
  • /usr/bin/tput setaf 1
  • '[' -z ']'
  • FANCYTTY=1
  • case "$FANCYTTY" in
  • true
  • /usr/bin/tput xenl
    ++ /usr/bin/tput cols
  • COLS=80
  • '[' 80 ']'
  • '[' 80 -gt 6 ']'
    ++ /usr/bin/expr 80 - 7
  • COL=73
  • log_use_plymouth
  • '[' n = y ']'
  • plymouth --ping
  • printf ' * Starting ElasticSearch Server '
    • Starting ElasticSearch Server ++ /usr/bin/expr 80 - 1
  • /usr/bin/tput hpa 79
    + printf ' '
    ++ pidofproc -p /var/run/elasticsearch.pid elasticsearch
    ++ local pidfile line i pids= status specified pid
    ++ pidfile=
    ++ specified=
    ++ OPTIND=1
    ++ getopts p: opt
    ++ case "$opt" in
    ++ pidfile=/var/run/elasticsearch.pid
    ++ specified=1
    ++ getopts p: opt
    ++ shift 2
    ++ base=elasticsearch
    ++ '[' '!' 1 ']'
    ++ '[' -n /var/run/elasticsearch.pid -a -r /var/run/elasticsearch.pid ']'
    ++ read pid
    ++ '[' -n 16987 ']'
    +++ kill -0 16987
    ++ ps 16987
    ++ return 1
  • pid=
  • '[' -n '' ']'
  • mkdir -p /var/log/elasticsearch /var/lib/elasticsearch /tmp/elasticsearch
  • chown elasticsearch:elasticsearch /var/log/elasticsearch /var/lib/elasticsearch /tmp/elasticsearch
  • touch /var/run/elasticsearch.pid
  • chown elasticsearch:elasticsearch /var/run/elasticsearch.pid
  • '[' -n 65535 ']'
  • ulimit -n 65535
  • '[' -n '' ']'
  • '[' -n 65535 ']'
  • sysctl -q -w vm.max_map_count=65535
    error: permission denied on key 'vm.max_map_count'
  • start-stop-daemon --start -b --user elasticsearch -c elasticsearch --pidfile /var/run/elasticsearch.pid --exec /usr/share/elasticsearch/bin/elasticsearch -- -p /var/run/elasticsearch.pid -Des.default.config=/etc/elasticsearch/elasticsearch.yml -Des.default.path.home=/usr/share/elasticsearch -Des.default.path.logs=/var/log/elasticsearch -Des.default.path.data=/var/lib/elasticsearch -Des.default.path.work=/tmp/elasticsearch -Des.default.path.conf=/etc/elasticsearch
  • log_end_msg 0
  • '[' -z 0 ']'
  • '[' 73 ']'
  • '[' -x /usr/bin/tput ']'
  • log_use_plymouth
  • '[' n = y ']'
  • plymouth --ping
  • printf '\r'
  • /usr/bin/tput hpa 73
    + '[' 0 -eq 0 ']'
  • echo '[ OK ]'
    [ OK ]
  • return 0
  • exit 0
@spinscale

This comment has been minimized.

Show comment
Hide comment
@spinscale

spinscale Feb 24, 2014

Member

can you run ps p $(cat /var/run/elasticsearch.pid) - this actually looks as if elasticsearch was started...

Member

spinscale commented Feb 24, 2014

can you run ps p $(cat /var/run/elasticsearch.pid) - this actually looks as if elasticsearch was started...

@dmikhaylov

This comment has been minimized.

Show comment
Hide comment
@dmikhaylov

dmikhaylov Feb 25, 2014

Returns just header, i've tried service elasticsearch status and it says * elasticsearch is not running.

Returns just header, i've tried service elasticsearch status and it says * elasticsearch is not running.

@spinscale

This comment has been minimized.

Show comment
Hide comment
@spinscale

spinscale Feb 25, 2014

Member

Can you make sure elasticsearch does not run, and try this on the commandline (as root!):

touch /var/run/elasticsearch.pid
chown elasticsearch:elasticsearch /var/run/elasticsearch.pid
start-stop-daemon -v --start --user elasticsearch -c elasticsearch --pidfile /var/run/elasticsearch.pid --exec /usr/share/elasticsearch/bin/elasticsearch -- -p /var/run/elasticsearch.pid -Des.default.config=/etc/elasticsearch/elasticsearch.yml -Des.default.path.home=/usr/share/elasticsearch -Des.default.path.logs=/var/log/elasticsearch -Des.default.path.data=/var/lib/elasticsearch -Des.default.path.work=/tmp/elasticsearch -Des.default.path.conf=/etc/elasticsearch

and paste the output here?

Member

spinscale commented Feb 25, 2014

Can you make sure elasticsearch does not run, and try this on the commandline (as root!):

touch /var/run/elasticsearch.pid
chown elasticsearch:elasticsearch /var/run/elasticsearch.pid
start-stop-daemon -v --start --user elasticsearch -c elasticsearch --pidfile /var/run/elasticsearch.pid --exec /usr/share/elasticsearch/bin/elasticsearch -- -p /var/run/elasticsearch.pid -Des.default.config=/etc/elasticsearch/elasticsearch.yml -Des.default.path.home=/usr/share/elasticsearch -Des.default.path.logs=/var/log/elasticsearch -Des.default.path.data=/var/lib/elasticsearch -Des.default.path.work=/tmp/elasticsearch -Des.default.path.conf=/etc/elasticsearch

and paste the output here?

@dmikhaylov

This comment has been minimized.

Show comment
Hide comment
@dmikhaylov

dmikhaylov Feb 25, 2014

{0.90.8}: Initialization Failed ...

  • ElasticSearchIllegalStateException[Failed to obtain node lock, is the following location writable?: [/var/data/elasticsearch/hostname]]
    IOException[failed to obtain lock on /var/data/elasticsearch/hostname/nodes/49]
    IOException[Cannot create directory: /var/data/elasticsearch/hostname/nodes/49]
    Turns out I just forgot to create /var/data directory. Now everything works. Thank you, @spinscale.

{0.90.8}: Initialization Failed ...

  • ElasticSearchIllegalStateException[Failed to obtain node lock, is the following location writable?: [/var/data/elasticsearch/hostname]]
    IOException[failed to obtain lock on /var/data/elasticsearch/hostname/nodes/49]
    IOException[Cannot create directory: /var/data/elasticsearch/hostname/nodes/49]
    Turns out I just forgot to create /var/data directory. Now everything works. Thank you, @spinscale.
@spinscale

This comment has been minimized.

Show comment
Hide comment
@spinscale

spinscale Feb 26, 2014

Member

@empirik One last question: Did this message also occur in the log file at /var/log/elasticsearch or was it just printed to stdout? Would be awesome if you could check it!

Member

spinscale commented Feb 26, 2014

@empirik One last question: Did this message also occur in the log file at /var/log/elasticsearch or was it just printed to stdout? Would be awesome if you could check it!

@dmikhaylov

This comment has been minimized.

Show comment
Hide comment
@dmikhaylov

dmikhaylov Feb 26, 2014

@spinscale I don't see this message in logs.

@spinscale I don't see this message in logs.

@derEremit

This comment has been minimized.

Show comment
Hide comment
@derEremit

derEremit Mar 16, 2014

Just for the record. Getting same error on startup in openvz, but elasticsearch runs without problems for now. A bit irritating as normaly a service start error means the service won't run. As opposed to a warning.
I expect without correct vm.max_map_count I should expect "only" performace problems?

Just for the record. Getting same error on startup in openvz, but elasticsearch runs without problems for now. A bit irritating as normaly a service start error means the service won't run. As opposed to a warning.
I expect without correct vm.max_map_count I should expect "only" performace problems?

@BanzaiMan BanzaiMan referenced this issue in travis-ci/travis-ci Mar 24, 2014

Closed

Error starting ElasticSearch server #2094

@spinscale

This comment has been minimized.

Show comment
Hide comment
@spinscale

spinscale Apr 25, 2014

Member

I dont know openvz enough, but not setting this setting can also result in lucene exceptions and indexing problems, it is not only about performance here - I dont how openvz is handling this. Can you get us any insight here @derEremit?

Member

spinscale commented Apr 25, 2014

I dont know openvz enough, but not setting this setting can also result in lucene exceptions and indexing problems, it is not only about performance here - I dont how openvz is handling this. Can you get us any insight here @derEremit?

@13h3r

This comment has been minimized.

Show comment
Hide comment
@13h3r

13h3r May 12, 2014

Got the same on openvz

13h3r commented May 12, 2014

Got the same on openvz

@kritik

This comment has been minimized.

Show comment
Hide comment
@kritik

kritik May 14, 2014

I see the same message on big index but after allocating more memmory elasticsearch starts at least :) Using OpenVZ too and elasticsearch 1.1.1.

kritik commented May 14, 2014

I see the same message on big index but after allocating more memmory elasticsearch starts at least :) Using OpenVZ too and elasticsearch 1.1.1.

@idanov

This comment has been minimized.

Show comment
Hide comment
@idanov

idanov Jun 3, 2014

Got the same on OpenVZ and elasticsearch 1.2.0.

idanov commented Jun 3, 2014

Got the same on OpenVZ and elasticsearch 1.2.0.

@r0mdau

This comment has been minimized.

Show comment
Hide comment
@r0mdau

r0mdau Jun 10, 2014

Got the same on OpenVZ and elasticsearch 1.2.0
Template : debian-7.0-x86_64.tar.gz
Host Server : Proxmox 3.1-21

r0mdau commented Jun 10, 2014

Got the same on OpenVZ and elasticsearch 1.2.0
Template : debian-7.0-x86_64.tar.gz
Host Server : Proxmox 3.1-21

@derEremit

This comment has been minimized.

Show comment
Hide comment
@derEremit

derEremit Jun 11, 2014

Basically openvz does not allow modifications of kernel parameters as these would affect the host and every other guest machine.
I think that setting should be removed from init scripts and put in a README.
The init script could check for the correct setting and output a warning but not set these kernel parameters itself!

Basically openvz does not allow modifications of kernel parameters as these would affect the host and every other guest machine.
I think that setting should be removed from init scripts and put in a README.
The init script could check for the correct setting and output a warning but not set these kernel parameters itself!

@joke2k

This comment has been minimized.

Show comment
Hide comment

joke2k commented Jun 26, 2014

👍

@scamianbas

This comment has been minimized.

Show comment
Hide comment
@scamianbas

scamianbas Jul 2, 2014

Hi all,
kinda newbie here.
I'm using Proxmox, Ubuntu OpenVZ container, Elasticsearch 1.2.1.
I had the same service starting issues and I fixed that by removing the "-d" option in DAEMON_OPTS (a directory path shoud have been provided here)
Also I changed the line
if [ -n "$MAX_MAP_COUNT" ]
with
if [ -n "$MAX_MAP_COUNT" ] && [ ! -f /proc/sys/vm/max_map_count ]
to address the unwanted sysctl issue.
Hope it helps.

Hi all,
kinda newbie here.
I'm using Proxmox, Ubuntu OpenVZ container, Elasticsearch 1.2.1.
I had the same service starting issues and I fixed that by removing the "-d" option in DAEMON_OPTS (a directory path shoud have been provided here)
Also I changed the line
if [ -n "$MAX_MAP_COUNT" ]
with
if [ -n "$MAX_MAP_COUNT" ] && [ ! -f /proc/sys/vm/max_map_count ]
to address the unwanted sysctl issue.
Hope it helps.

@spinscale spinscale added the packaging label Jul 18, 2014

@adeleglise

This comment has been minimized.

Show comment
Hide comment
@adeleglise

adeleglise Aug 10, 2014

Hi all,

Thanks to scamianbas for his tips, I tested this on proxmox 3.2-4, debian7-x64 template, works like a charm !

Thanks to the elasticsearch guys too for this great piece of software ;)

Hi all,

Thanks to scamianbas for his tips, I tested this on proxmox 3.2-4, debian7-x64 template, works like a charm !

Thanks to the elasticsearch guys too for this great piece of software ;)

@andykillen

This comment has been minimized.

Show comment
Hide comment
@andykillen

andykillen Aug 12, 2014

FYI: fresh install of Unbuntu 12.4 with elastic search 1.3.1 over the top, following this Gist (easy way) for install https://gist.github.com/wingdspur/2026107

I get the error

  • Starting Elasticsearch Server
    error: permission denied on key 'vm.max_map_count'

when I do a ps check, I get

ps p $(cat /var/run/elasticsearch.pid)
PID TTY STAT TIME COMMAND
8246 ? Sl 0:08 /usr/lib/jvm/java-7-openjdk-i386//bin/java -Xms256m -Xmx1g -Xss256k -Djava.awt.headless=true -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=75 -XX

and finally when doing "service elasticsearch status"

it says it is running.

So the error has a slightly different prefix (error: and not sysctl:) but as with other information above it is not stopping the server. If needed I have the screen output with set -x in the elasticsearch config file.

FYI: fresh install of Unbuntu 12.4 with elastic search 1.3.1 over the top, following this Gist (easy way) for install https://gist.github.com/wingdspur/2026107

I get the error

  • Starting Elasticsearch Server
    error: permission denied on key 'vm.max_map_count'

when I do a ps check, I get

ps p $(cat /var/run/elasticsearch.pid)
PID TTY STAT TIME COMMAND
8246 ? Sl 0:08 /usr/lib/jvm/java-7-openjdk-i386//bin/java -Xms256m -Xmx1g -Xss256k -Djava.awt.headless=true -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=75 -XX

and finally when doing "service elasticsearch status"

it says it is running.

So the error has a slightly different prefix (error: and not sysctl:) but as with other information above it is not stopping the server. If needed I have the screen output with set -x in the elasticsearch config file.

@grepwood

This comment has been minimized.

Show comment
Hide comment
@grepwood

grepwood Sep 2, 2014

I'm having the same issue on CentOS 6.5 with elasticsearch 1.3.2 in OpenVZ.
ps p $(cat /var/run/elasticsearch/elasticsearch.pid)
PID TTY STAT TIME COMMAND
1132 ? Sl 0:05 /usr/bin/java -Xms256m -Xmx1g -Xss256k -Djava.awt.headless=true -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=75 -XX:+UseCMSInitiatingOccupancyOnly -XX:+HeapDumpOnOutOfMemoryError -XX:+DisableExplicitGC -Delastics
Just like andykillen, the service is running after all.

grepwood commented Sep 2, 2014

I'm having the same issue on CentOS 6.5 with elasticsearch 1.3.2 in OpenVZ.
ps p $(cat /var/run/elasticsearch/elasticsearch.pid)
PID TTY STAT TIME COMMAND
1132 ? Sl 0:05 /usr/bin/java -Xms256m -Xmx1g -Xss256k -Djava.awt.headless=true -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=75 -XX:+UseCMSInitiatingOccupancyOnly -XX:+HeapDumpOnOutOfMemoryError -XX:+DisableExplicitGC -Delastics
Just like andykillen, the service is running after all.

@deric

This comment has been minimized.

Show comment
Hide comment
@deric

deric Sep 30, 2014

Same issue with LXC and Ubuntu 14.04

sysctl: permission denied on key 'vm.max_map_count'

though elasticsearch is running, is it a huge problem for production environment?

deric commented Sep 30, 2014

Same issue with LXC and Ubuntu 14.04

sysctl: permission denied on key 'vm.max_map_count'

though elasticsearch is running, is it a huge problem for production environment?

@karmux

This comment has been minimized.

Show comment
Hide comment
@karmux

karmux Oct 29, 2014

I also get this error on VPS running Ubuntu 14.04 when I (re)start Elasticsearch but is running at least.

sysctl: permission denied on key 'vm.max_map_count'

karmux commented Oct 29, 2014

I also get this error on VPS running Ubuntu 14.04 when I (re)start Elasticsearch but is running at least.

sysctl: permission denied on key 'vm.max_map_count'
@sts

This comment has been minimized.

Show comment
Hide comment
@sts

sts Nov 13, 2014

Can someone please merge this? This works! 👍 :shipit:

if [ -n "$MAX_MAP_COUNT" ]
with
if [ -n "$MAX_MAP_COUNT" ] && [ ! -f /proc/sys/vm/max_map_count ]

sts commented Nov 13, 2014

Can someone please merge this? This works! 👍 :shipit:

if [ -n "$MAX_MAP_COUNT" ]
with
if [ -n "$MAX_MAP_COUNT" ] && [ ! -f /proc/sys/vm/max_map_count ]

@spinscale

This comment has been minimized.

Show comment
Hide comment
@spinscale

spinscale Nov 13, 2014

Member

@sts, shouldnt the check be vice versa and only done if the file exists and thus without the negation? I am confused or maybe misunderstanding the intent

Member

spinscale commented Nov 13, 2014

@sts, shouldnt the check be vice versa and only done if the file exists and thus without the negation? I am confused or maybe misunderstanding the intent

@alexgarel

This comment has been minimized.

Show comment
Hide comment
@alexgarel

alexgarel Nov 17, 2014

@sts to avoid the warning you can also edit /etc/default/elasticsearch to set MAX_MAP_COUNT with an empty value, no need to fix the startup script.

@sts to avoid the warning you can also edit /etc/default/elasticsearch to set MAX_MAP_COUNT with an empty value, no need to fix the startup script.

@grepwood

This comment has been minimized.

Show comment
Hide comment
@grepwood

grepwood Nov 18, 2014

@alexgarel I think it'd be very nice of ES to construct /etc/default/elasticsearch that has MAX_MAP_COUNT set to a null value when an offending environment like OpenVZ is detected as the host of ES, or otherwise, whatever it is meant to be set to.

@alexgarel I think it'd be very nice of ES to construct /etc/default/elasticsearch that has MAX_MAP_COUNT set to a null value when an offending environment like OpenVZ is detected as the host of ES, or otherwise, whatever it is meant to be set to.

spinscale added a commit to spinscale/elasticsearch that referenced this issue Dec 8, 2014

Packaging: Check if proc file exists before calling sysctl
The packaged init scripts could return an error, if the file
/proc/sys/vm/max_map_count was not existing and we still called
sysctl.

This is primarly to prevent confusing error messages when elasticsearch
is started under virtualized environments without a proc file system.

Closes #4978

@spinscale spinscale closed this in #8793 Dec 8, 2014

spinscale added a commit that referenced this issue Dec 8, 2014

Packaging: Check if proc file exists before calling sysctl
The packaged init scripts could return an error, if the file
/proc/sys/vm/max_map_count was not existing and we still called
sysctl.

This is primarly to prevent confusing error messages when elasticsearch
is started under virtualized environments without a proc file system.

Closes #4978
@marfago

This comment has been minimized.

Show comment
Hide comment
@marfago

marfago Jan 26, 2015

I'm still experiencing the problem with es 1.4.2. In my openvz guest (vps) the proc file already exists:

cat /proc/sys/vm/max_map_count
65530

but I get the same error

sysctl: permission denied on key 'vm.max_map_count'

marfago commented Jan 26, 2015

I'm still experiencing the problem with es 1.4.2. In my openvz guest (vps) the proc file already exists:

cat /proc/sys/vm/max_map_count
65530

but I get the same error

sysctl: permission denied on key 'vm.max_map_count'

@TomArrow

This comment has been minimized.

Show comment
Hide comment
@TomArrow

TomArrow Aug 24, 2015

perfect, solved. thank you.

perfect, solved. thank you.

@ccfontes

This comment has been minimized.

Show comment
Hide comment
@ccfontes

ccfontes Sep 3, 2015

Also getting:

* Starting Elasticsearch Server                                                                                                                                                  
sysctl: permission denied on key 'vm.max_map_count'

on OpenVZ, but already running Elastic 1.7.1. Shouldn't this issue be solved already?

ccfontes commented Sep 3, 2015

Also getting:

* Starting Elasticsearch Server                                                                                                                                                  
sysctl: permission denied on key 'vm.max_map_count'

on OpenVZ, but already running Elastic 1.7.1. Shouldn't this issue be solved already?

@joshuajonah

This comment has been minimized.

Show comment
Hide comment
@joshuajonah

joshuajonah Oct 20, 2015

This is insane. I guess I'm going to change over to a KVM VPS.

This is insane. I guess I'm going to change over to a KVM VPS.

@TomArrow

This comment has been minimized.

Show comment
Hide comment
@TomArrow

TomArrow Oct 20, 2015

You may want to try to execute the command from the init script. To me, it revealed that it really was all just a problem with the wrong JDK version. The vm.max_map_count error was basically just a demonic distraction from the true problem.

You may want to try to execute the command from the init script. To me, it revealed that it really was all just a problem with the wrong JDK version. The vm.max_map_count error was basically just a demonic distraction from the true problem.

@jdkcn

This comment has been minimized.

Show comment
Hide comment
@jdkcn

jdkcn Oct 29, 2015

the Elasticsearch 2.0 has the same problem.

but the server started up.

root@es0:~# /etc/init.d/elasticsearch start
[....] Starting Elasticsearch Server:sysctl: permission denied on key 'vm.max_map_count'
. ok 

jdkcn commented Oct 29, 2015

the Elasticsearch 2.0 has the same problem.

but the server started up.

root@es0:~# /etc/init.d/elasticsearch start
[....] Starting Elasticsearch Server:sysctl: permission denied on key 'vm.max_map_count'
. ok 
@spinscale

This comment has been minimized.

Show comment
Hide comment
@spinscale

spinscale Oct 29, 2015

Member

This has nothing to do with sigar. It is just the init script trying to access a file in the proc filesystem... And falling due to not being able to access it

Member

spinscale commented Oct 29, 2015

This has nothing to do with sigar. It is just the init script trying to access a file in the proc filesystem... And falling due to not being able to access it

@grepwood

This comment has been minimized.

Show comment
Hide comment
@grepwood

grepwood Oct 29, 2015

Since this is exclusively a problem with OpenVZ, shouldn't Elasticsearch not attempt to access that file if OpenVZ is detected?

Since this is exclusively a problem with OpenVZ, shouldn't Elasticsearch not attempt to access that file if OpenVZ is detected?

@alexgarel

This comment has been minimized.

Show comment
Hide comment
@alexgarel

alexgarel Oct 29, 2015

This is not only true for OpenVZ, this is also true for LXC or Docker, every time you have a read only access to /sys or /proc.
But in some way, this is a warning, not a show stopper.
What we need here is pedagogy. If the script can't write on /sys, just explain this could degrade performance. In the case of a container, the user knows if he sets the /sys parameter to its right value on the host.
If some of the commiter is reading, I suggest to change the script to catch sysctl error and emit a warning message, telling which parameter it was not able to change, to which value.

This is not only true for OpenVZ, this is also true for LXC or Docker, every time you have a read only access to /sys or /proc.
But in some way, this is a warning, not a show stopper.
What we need here is pedagogy. If the script can't write on /sys, just explain this could degrade performance. In the case of a container, the user knows if he sets the /sys parameter to its right value on the host.
If some of the commiter is reading, I suggest to change the script to catch sysctl error and emit a warning message, telling which parameter it was not able to change, to which value.

@clintongormley

This comment has been minimized.

Show comment
Hide comment
@clintongormley

clintongormley Oct 30, 2015

Member

the startup script now has this:

if [ -n "$MAX_MAP_COUNT" -a -f /proc/sys/vm/max_map_count ]; then

should we change that to check if /proc/sys/vm/max_map_count is writable instead of just -f?

Member

clintongormley commented Oct 30, 2015

the startup script now has this:

if [ -n "$MAX_MAP_COUNT" -a -f /proc/sys/vm/max_map_count ]; then

should we change that to check if /proc/sys/vm/max_map_count is writable instead of just -f?

@alexgarel

This comment has been minimized.

Show comment
Hide comment
@alexgarel

alexgarel Oct 30, 2015

yes this checking its writable is a good idea. Maybe emitting a warning if it exists but is not writable.

yes this checking its writable is a good idea. Maybe emitting a warning if it exists but is not writable.

@dagatsoin

This comment has been minimized.

Show comment
Hide comment
@dagatsoin

dagatsoin Nov 26, 2015

Update on this? Could this still cause problem with Lucen? I have this error too:

[root@vps1569 init.d]$ service elasticsearch restart
Stopping elasticsearch:                                    [  OK  ]
error: permission denied on key 'vm.max_map_count'
Starting elasticsearch: log4j:WARN No appenders could be found for logger (common).
log4j:WARN Please initialize the log4j system properly.
log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for more info.
                                                           [  OK  ]

Update on this? Could this still cause problem with Lucen? I have this error too:

[root@vps1569 init.d]$ service elasticsearch restart
Stopping elasticsearch:                                    [  OK  ]
error: permission denied on key 'vm.max_map_count'
Starting elasticsearch: log4j:WARN No appenders could be found for logger (common).
log4j:WARN Please initialize the log4j system properly.
log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for more info.
                                                           [  OK  ]
@jogaco

This comment has been minimized.

Show comment
Hide comment
@jogaco

jogaco Dec 23, 2015

Upgrading from 1.7 to 2.1 I got the same error:

 * Starting Elasticsearch Server
sysctl: permission denied on key 'vm.max_map_count'

Using Ubuntu 14.04.1 LTS,
The service is working luckily. Consequences of this error, anyone?

jogaco commented Dec 23, 2015

Upgrading from 1.7 to 2.1 I got the same error:

 * Starting Elasticsearch Server
sysctl: permission denied on key 'vm.max_map_count'

Using Ubuntu 14.04.1 LTS,
The service is working luckily. Consequences of this error, anyone?

@grepwood

This comment has been minimized.

Show comment
Hide comment
@grepwood

grepwood Dec 28, 2015

@jogaco Absolutely no practical consequences other than having this message in the logs

@jogaco Absolutely no practical consequences other than having this message in the logs

@karmi

This comment has been minimized.

Show comment
Hide comment
@karmi

karmi Mar 10, 2016

Member

@spinscale, this issue is still linked from the TravisCI docs, maybe we can look into it?

Member

karmi commented Mar 10, 2016

@spinscale, this issue is still linked from the TravisCI docs, maybe we can look into it?

@clintongormley clintongormley added the >bug label Mar 14, 2016

@spinscale

This comment has been minimized.

Show comment
Hide comment
@spinscale

spinscale Mar 18, 2016

Member

@karmi it is trivial to add another check if the proc file is writable and silence out the message, I just tested that locally on non OpenVZ and everything works as expected.

What I dont know is, if just adding another check, that checks if the file in the proc file system is writable, actually changes anything for OpenVZ users. Maybe one OpenVZ user can shed some light on this? If we check for being able to write /proc/sys/vm/max_map_count instead that it is being a file (what we do now), would the sysctl call not be done on OpenVZ?

Member

spinscale commented Mar 18, 2016

@karmi it is trivial to add another check if the proc file is writable and silence out the message, I just tested that locally on non OpenVZ and everything works as expected.

What I dont know is, if just adding another check, that checks if the file in the proc file system is writable, actually changes anything for OpenVZ users. Maybe one OpenVZ user can shed some light on this? If we check for being able to write /proc/sys/vm/max_map_count instead that it is being a file (what we do now), would the sysctl call not be done on OpenVZ?

@Altareq

This comment has been minimized.

Show comment
Hide comment
@Altareq

Altareq Apr 22, 2016

same problem on ES 2.3.0 Ubuntu 14.04

Altareq commented Apr 22, 2016

same problem on ES 2.3.0 Ubuntu 14.04

@rectoid

This comment has been minimized.

Show comment
Hide comment
@rectoid

rectoid Apr 27, 2016

there is no solutions for this problem? fresh install of ubuntu server will be fix them?

rectoid commented Apr 27, 2016

there is no solutions for this problem? fresh install of ubuntu server will be fix them?

@rectoid

This comment has been minimized.

Show comment
Hide comment
@rectoid

rectoid Apr 28, 2016

this is caused on ubuntu 14 on proc/sys/vm permitted

rectoid commented Apr 28, 2016

this is caused on ubuntu 14 on proc/sys/vm permitted

@rectoid

This comment has been minimized.

Show comment
Hide comment
@rectoid

rectoid Apr 28, 2016

now i know the problem is on server host is use openvz or any virtualization that doesnt support editing

rectoid commented Apr 28, 2016

now i know the problem is on server host is use openvz or any virtualization that doesnt support editing

@rectoid

This comment has been minimized.

Show comment
Hide comment
@rectoid

rectoid Apr 28, 2016

then it is posible on how to make elasticsearch and java not without editing this request

rectoid commented Apr 28, 2016

then it is posible on how to make elasticsearch and java not without editing this request

@rectoid

This comment has been minimized.

Show comment
Hide comment
@rectoid

rectoid Apr 28, 2016

omg help mee

rectoid commented Apr 28, 2016

omg help mee

@grepwood

This comment has been minimized.

Show comment
Hide comment
@grepwood

grepwood Apr 28, 2016

@rectoid The bug isn't causing any actual issues. Your Elasticsearch will work fine. It's just annoying to see in the logs.

I can't believe it's been over 2 years.

@rectoid The bug isn't causing any actual issues. Your Elasticsearch will work fine. It's just annoying to see in the logs.

I can't believe it's been over 2 years.

@adamgontarz

This comment has been minimized.

Show comment
Hide comment
@adamgontarz

adamgontarz Jun 23, 2016

on /etc/init.d/elasticsearch init script comment lines:

#       if [ -n "$MAX_MAP_COUNT" ]; then
#               sysctl -q -w vm.max_map_count=$MAX_MAP_COUNT
#       fi

adamgontarz commented Jun 23, 2016

on /etc/init.d/elasticsearch init script comment lines:

#       if [ -n "$MAX_MAP_COUNT" ]; then
#               sysctl -q -w vm.max_map_count=$MAX_MAP_COUNT
#       fi
@xenu256

This comment has been minimized.

Show comment
Hide comment
@xenu256

xenu256 Oct 16, 2016

Same on 2.4.1, Ubuntu 14.04.

xenu256 commented Oct 16, 2016

Same on 2.4.1, Ubuntu 14.04.

@arypurnomoz

This comment has been minimized.

Show comment
Hide comment
@arypurnomoz

arypurnomoz Oct 29, 2016

steps that i took to make es 5 run in an environment when i can't change vm.max_map_count

  1. make es bind to localhost, (when binding to localhost es will start development mode, which wont do the check)
  2. use nginx to forward http traffic to es, or you can use iptables to route the tcp request from outside network to localhost

but remember, es will run on DEVELOPMENT mode

here is my workaround for making it run inside docker container
https://gist.github.com/arypurnomoz/8d24155f024f8d4b6bee6b053c6e47d9

arypurnomoz commented Oct 29, 2016

steps that i took to make es 5 run in an environment when i can't change vm.max_map_count

  1. make es bind to localhost, (when binding to localhost es will start development mode, which wont do the check)
  2. use nginx to forward http traffic to es, or you can use iptables to route the tcp request from outside network to localhost

but remember, es will run on DEVELOPMENT mode

here is my workaround for making it run inside docker container
https://gist.github.com/arypurnomoz/8d24155f024f8d4b6bee6b053c6e47d9

@florian-asche

This comment has been minimized.

Show comment
Hide comment
@florian-asche

florian-asche Oct 29, 2016

You should not have to. My is running fine, except that error/warning message...

You should not have to. My is running fine, except that error/warning message...

@clintongormley

This comment has been minimized.

Show comment
Hide comment
@clintongormley

clintongormley Nov 6, 2016

Member

As of 5.0, Elasticsearch will not start in production mode if vm.max_map_count is not high enough. Silencing the warning when we are not able to apply the MAX_MAP_COUNT setting on openvz will just make debugging the issue harder, as it will not be obvious why the setting is not being applied. Instead, if you are running on a system where you cannot set vm.max_map_count, but it is set to be high enough for Elasticsearch's bootstrap checks, then you can silence the warning by removing the MAX_MAP_COUNT setting. If the value on your system is NOT high enough, then your cluster is going to crash and burn at some stage and you will lose data. Instead of trying to work around it with hacks like #4978 (comment), you should either speak to your sysadmin to configure vm.max_map_count correctly, or move to a platform where you can set it.

Member

clintongormley commented Nov 6, 2016

As of 5.0, Elasticsearch will not start in production mode if vm.max_map_count is not high enough. Silencing the warning when we are not able to apply the MAX_MAP_COUNT setting on openvz will just make debugging the issue harder, as it will not be obvious why the setting is not being applied. Instead, if you are running on a system where you cannot set vm.max_map_count, but it is set to be high enough for Elasticsearch's bootstrap checks, then you can silence the warning by removing the MAX_MAP_COUNT setting. If the value on your system is NOT high enough, then your cluster is going to crash and burn at some stage and you will lose data. Instead of trying to work around it with hacks like #4978 (comment), you should either speak to your sysadmin to configure vm.max_map_count correctly, or move to a platform where you can set it.

@jasontedor

This comment has been minimized.

Show comment
Hide comment
@jasontedor

jasontedor Nov 7, 2016

Member

@arypurnomoz Your workaround is overly complicated if all you want to do is expose a node via HTTP on an interface other than localhost. You can set http.host independently of transport.host (network.host sets both); the bootstrap checks are only enforced if a node is able to form a cluster with other instances not on localhost.

Member

jasontedor commented Nov 7, 2016

@arypurnomoz Your workaround is overly complicated if all you want to do is expose a node via HTTP on an interface other than localhost. You can set http.host independently of transport.host (network.host sets both); the bootstrap checks are only enforced if a node is able to form a cluster with other instances not on localhost.

@vanthome

This comment has been minimized.

Show comment
Hide comment
@vanthome

vanthome Dec 16, 2016

you should provide a flag to prevent this check or better do not conduct it in development mode. this currently prevents me from running tests on travis.ci.

you should provide a flag to prevent this check or better do not conduct it in development mode. this currently prevents me from running tests on travis.ci.

@tianon tianon referenced this issue in docker-library/elasticsearch Dec 19, 2016

Closed

Figure out what's up with 5.0 #98

@JESWINKNINAN

This comment has been minimized.

Show comment
Hide comment
@JESWINKNINAN

JESWINKNINAN Dec 29, 2016

I have this issue before and solved by running my docker container in privileged mode, The actual reason behind this error is quite simple, Elasticsearch needs to change the "vm.max_map_count" to run, so changing via sysctl by Elasticseach itself and action is denied due to lack of permission. The issue will occur even the it is also a root user(Docker).

Simply run the container in privileged mode and this will fix the similar type of issues.

root@Zion:/home/jeswin/dockerproject# docker run -i -t --privileged ecc4953c8296 "/bin/bash"

JESWINKNINAN commented Dec 29, 2016

I have this issue before and solved by running my docker container in privileged mode, The actual reason behind this error is quite simple, Elasticsearch needs to change the "vm.max_map_count" to run, so changing via sysctl by Elasticseach itself and action is denied due to lack of permission. The issue will occur even the it is also a root user(Docker).

Simply run the container in privileged mode and this will fix the similar type of issues.

root@Zion:/home/jeswin/dockerproject# docker run -i -t --privileged ecc4953c8296 "/bin/bash"

dieterve added a commit to madewithlove/elasticsearcher that referenced this issue Jan 20, 2017

Run elasticsearch in development mode for test builds
When elasticsearch is bound to localhost it runs in development mode. This mode makes a few startup checks of elasticsearch
less strict (they become warnings), allowing it to boot anyway.

On circleci its servers the value for  is too low and elasticsearch wont start. So we make sure we
are running in dev mode so we can at least run our tests

elastic/elasticsearch#4978 (comment)
@x-itec

This comment has been minimized.

Show comment
Hide comment
@x-itec

x-itec Aug 11, 2017

This problem really drives me mad with docker !!!!!!!! --privileged does not work anymore, nothing works anymore!!!! memory is set, but not checked correctly by ES5.x so it tries to write for no reason! result: ERROR

x-itec commented Aug 11, 2017

This problem really drives me mad with docker !!!!!!!! --privileged does not work anymore, nothing works anymore!!!! memory is set, but not checked correctly by ES5.x so it tries to write for no reason! result: ERROR

@davron112

This comment has been minimized.

Show comment
Hide comment
@davron112

davron112 May 11, 2018

My version: elasticsearch: 5.6.4 (but not working 6.2.3)
I added elasticsearch.yml : network.bind_host: "0.0.0.0"
To set this value permanently, update the vm.max_map_count setting in /etc/sysctl.conf.
vm.max_map_count=262144
To verify after rebooting, runsysctl vm.max_map_count.

docker-compose build elasticsearch
docker-compose up -d elasticsearch
docker-compose ps (double, because first worked, but second not worked)

result:

laradock_elasticsearch /bin/bash bin/es- Up 0.0.0.0:9200->9200/tcp

davron112 commented May 11, 2018

My version: elasticsearch: 5.6.4 (but not working 6.2.3)
I added elasticsearch.yml : network.bind_host: "0.0.0.0"
To set this value permanently, update the vm.max_map_count setting in /etc/sysctl.conf.
vm.max_map_count=262144
To verify after rebooting, runsysctl vm.max_map_count.

docker-compose build elasticsearch
docker-compose up -d elasticsearch
docker-compose ps (double, because first worked, but second not worked)

result:

laradock_elasticsearch /bin/bash bin/es- Up 0.0.0.0:9200->9200/tcp

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment