I have elasticsearch up and running in a Docker container and accessible from other containers with http://elasticsearch. I'm trying to connect up Kibana and no matter what I try, the container simply exits with error code 0 and with no logs whatsoever (i.e. when running docker logs [id])
I've tried both the kibana and kibana-oss versions. I've tried diabling x-pack, I've tried turning on verbose logging. Always with the same results.
I've also tried attaching onto /bin/bash within the container and running the kibana start command directly. Again, nothing.
Either I've missed something massively obvious or I'm going insane... I've searched in this forum, in GitHub issues and on Google/StackOverflow with no similar scenarios found..
Is the Kibana container able to resolve "http://elasticsearch"? If not, it won't be able to connect to the Elasticsearch container, and won't start up. If that's the case though, you should see a message about that in the logs, which brings me to my next question; what do you see in the Kibana logs?
Sounds like you could be running out of memory. If you are not running Docker on real Linux, but Windows or macOS instead, make sure you've bumped the memory in the VM as shown in: https://github.com/elastic/stack-docker#prerequisites
When there are no logs it helps to have docker events running while you run your kibana container to see what's happening in the background.
Oh and I forgot to add - I'm running it on 'real' Linux:
$ cat /etc/*release
NAME="Red Hat Enterprise Linux Server"
VERSION="7.3 (Maipo)"
ID="rhel"
ID_LIKE="fedora"
VERSION_ID="7.3"
PRETTY_NAME="Red Hat Enterprise Linux Server 7.3 (Maipo)"
Also noticed the output from docker info that you pasted in the GH issue.
Possibly not related to the issue you are reporting, but the output from docker info provides some warning that would certainly cause issues in the future:
WARNING: overlay: the backing xfs filesystem is formatted without d_type support, which leads to incorrect behavior.
Reformat the filesystem with ftype=1 to enable d_type support.
Running without d_type support will not be supported in future releases.
WARNING: bridge-nf-call-ip6tables is disabled
Thanks for clarifying, unfortunately I am constrained by my environment at the moment and am unable to use your Vagrant script. Thank you for providing it though. The warnings will be addressed in the future.
I've done a little more digging and it seems to fall down to the node installation. Using this Dockerfile works fine. But if I switch the version of node to the same as packaged with Kibana (v6.11.5) I get exactly the same symptoms.. (quits with exit code 0)
For now I shall just use my own image as I don't have any more time to debug unfortunately.
Thank you for your help though, and maybe this will help someone else in the future..
Apache, Apache Lucene, Apache Hadoop, Hadoop, HDFS and the yellow elephant
logo are trademarks of the
Apache Software Foundation
in the United States and/or other countries.