Kibana startup fails - Cannot find module 'source-map'

Anyone else got this, and know a fix for it?

$ ./bin/kibana plugin --install elastic/sense
Installing sense
Attempting to extract from
Downloading 318236 bytes....................
Extraction complete
Optimizing and caching browser bundles...
Plugin installation complete
$ ./bin/kibana
  log   [10:42:29.255] [info][optimize] Optimizing and caching bundles for sense, kibana and statusPage. This may take a few minutes
  log   [10:43:14.232] [fatal] Error: Optimizations failure.

    ERROR in ./src/ui/public/styles/dark-variables.less
    Module build failed: ModuleBuildError: Module build failed: Cannot find module 'source-map'
     @ undefined (line undefined, column undefined)
        at DependenciesBlock.onModuleBuildFailed (/Users/dan/kibana-4.3.1-darwin-x64/node_modules/webpack/node_modules/webpack-core/lib/NormalModuleMixin.js:315:19)

Versions :-

OSX 10.10.5
Java 8u66
Node v0.12.3

I was just following the docs at :frowning:

Update :-

  • Tried a clean install without Sense plugin - same error
  • Tried upgrading to node 0.12.9 which is mentioned in the package.json - same error
  • Tried "npm cache clear" first - same error
  • nvm install v4.2.4 (official stable version) - same error

There's multiple errors - seems to be all failing when optimising all the Less files.

Are you running a development version of Kibana, or the 4.3.1 build from the website?

If you're running a build that you downloaded, it ships with its own version of nodejs, which should include everything it needs to run.

Sadly it's the 4.3.1 version from the website.

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.

Didn't really need Kibana right now anyway :slight_smile:

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...

No need - I think I've figured it out!

Something you just wrote must have triggered a useful thought in my head ... I checked my environment and remembered I had NODE_ENV=development set.

export NODE_ENV=production

Voila! It works. Perhaps the distributed bin/kibana script needs to warn about running in "development" mode?

Great, glad you got it working.

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...

Hrm, maybe I'm wrong about the cause. There's a bit in the server start config that uses the NODE_ENV and falls back to production if it's not set.

So if you have a global NODE_ENV setting on your machine, that could be causing this issue.

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:

NODE_ENV=production bin/kibana

I was having the same issue with my global NODE_ENV setting as development, setting it to production worked for me.

cd /usr/local/Cellar/kibana/4.5.1 ----your dir
and npm install source-map


This is still the case. Kind of a problem, no?

Devs with this set for apps we are developing can't necessarily unset this (except on projects using dotenv).

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.