Closed sourcecode-glitch closed 2 years ago
I am wondering if this could be because this repo uses one jvm.options
file regardless of the ES version. This may be related to #738
Hi @sourcecode-glitch, without digging too much, I think this could be related to deploying the playbook as user root (remote_user: root
), did you try with using become: yes
which is the recommended way instead?
Thanks for the suggestion but it did not work with become. I get exactly the same result.
Just for completeness, this is the diff compared with the previous version:
@@ -2,7 +2,7 @@
- name: Install elasticsearch
hosts: all
serial: 1
- remote_user: root
+ become: yes
roles:
- role: 'elasticsearch'
es_instance_name: "{{ ansible_nodename }}"
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
still valid
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
This issue has been automatically closed because it has not had recent activity since being marked as stale.
Elasticsearch version: Version: 6.1.2, Build: 5b1fea5/2018-01-10T02:35:59.208Z
Role version: v7.12.0
JVM version (
java -version
): 1.8.0_275OS version (
uname -a
if on a Unix-like system):Linux nosql1 4.9.0-9-amd64 #1 SMP Debian 4.9.168-1+deb9u2 (2019-05-13) x86_64 GNU/Linux
Description of the problem including expected versus actual behaviour: The role times out at the "Wait for elasticsearch to startup" task instead of correctly starting. It seems like the env var
${ES_TMPDIR}
injvm.options
is not resolved, therefore it tries to find a directory literally called "$ES_TMPDIR".I am running this via molecule on a vagrant VM (though I don't expect this to be important for this issue).
Playbook:
Provide logs from Ansible:
These are only the last lines. Please see the full log in case you need more details.
ES Logs if relevant:
When starting the elasticsearch binary directly from command line there is a much more detailed java stacktrace.
It includes the line
Caused by: java.nio.file.AccessDeniedException: /home/vagrant/${ES_TMPDIR}
so it seems like the environment variable is not resolved. The env var is defined as/tmp
: