I tried renaming the node folder in the distribution to node.bak, so that
the startup script uses my locally installed version instead. Still no
luck. I assume there's something odd with the node_modules supplied,
perhaps conflicting with a global installed module that I have somewhere.
You definitely do not want to use the system node install. We ship with it for a reason; we've tested it and know that it's ready to go.
It is possible we shipped with an issue here, but I'm pretty sure when we QA'd that release, we tested it with a number of plugins, Sense included. I'll spend a little time today trying to recreate your issue, just to be sure...
The build should be running in production mode by default, so I'm not sure why you had to explicitly specify that. I wonder if it's related to that bug I linked to or not, it's possible that it's still falling back to your system version of node, which it should not do from the build...
I had some issue with running the server and the issue was also caused by NODE_ENV being set to development. So the following works to work around this:
Yeah, I agree that the requirement to specify NODE_ENV isn't great. And I haven't run into it myself, but I'm guessing it's still a problem in the latest version too (4.5.2).
I'd encourage you to open an issue for it, and include some information about your specific case.
In the meantime, you can set NODE_ENV for just Kibana as part of the startup command, instead of changing it system-wide, as @AndyPotanin pointed out above. However, if you are using one of the packages, you'll likely have to stop the service and run the binary by hand with the production setting. There may be a way to specify it in the startup script too, but I'm not well versed in Linux startup scripts.
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.