kibana --version should not complain about not being able to optimize whatever.

[jsoref]

Kibana version:
6.8.0

Server OS version:
Ubuntu 18.04.2 LTS

Original install method (e.g. download page, yum, from source, etc.):
apt: http://artifacts.elastic.co/packages/6.x/apt stable/main

Describe the bug:

Steps to reproduce:

ubuntu@kibana $ /usr/share/kibana/bin/kibana --version
6.8.0
fs.js:115
    throw err;
    ^

Error: EACCES: permission denied, open '/usr/share/kibana/optimize/.babelcache.json'
    at Object.openSync (fs.js:439:3)
    at Object.writeFileSync (fs.js:1190:35)
    at process.save (/usr/share/kibana/node_modules/babel-register/lib/cache.js:48:16)
    at process.emit (events.js:189:13)
    at process.exit (internal/process/per_thread.js:168:15)
    at Command.<anonymous> (/usr/share/kibana/node_modules/commander/index.js:820:13)
    at Command.emit (events.js:194:15)
    at Command.parseOptions (/usr/share/kibana/node_modules/commander/index.js:697:14)
    at Command.<anonymous> (/usr/share/kibana/src/cli/command.js:109:22)
    at Command.wrapper [as parseOptions] (/usr/share/kibana/node_modules/lodash/index.js:3636:19)

Expected behavior:

6.8.0

with an exit value of 0

[elasticmachine]

Pinging @elastic/kibana-operations

[spalger]

Hey @jsoref, this is happening because some of the internal cache files that Kibana uses to run efficiently have the wrong permissions. Every kibana installation requires write access to its internal optimize directory, even for basic operation like printing out the version information.

Can you please walk us through how you installed Kibana? What happened after that? Were there any errors in the installation process? What about afterward? Can you share the output of ls -la /usr/share/kibana/optimize?

[jsoref]

At some point I ran the plug-in install task as root because your documentation is terrible.

I don't care that your cache isn't behaving the way you want it to.

When a user runs --version, they do not expect an optimization task. They asked a single question and expect a single answer, which your software is able to perform. That's all.

If you insist on performing an optimization task, you should swallow any errors you encounter.

[spalger]

Alright, please don't lash out at me, I'm trying to help.

Unfortunately we don't control the errors because they happen out of band and "optimization" is somewhat of a misnomer, it's transpiling things like import statements so that they code can be executed, which isn't something we can ignore, it's required for the code to run.

[jsoref]

In this case, it clearly isn't, since the version code has already run.

[spalger]

Fair enough, writing to the cache only happens at the end of the process, after the transpiler has run and the code has executed, which is why it's after the 6.0.0 in the output (which I didn't notice at first).

Would you like to suggest how we can improve the docs to avoid this type of issue in the first place?

I'm personally a pretty big fan of never swallowing errors, since they can be very valuable clues when trying to understand why other, seemingly unrelated things, aren't working. We could potentially request changes in our upstream package providers to make sure this error is printed to stderr instead of stdout, in case you were trying to collect the version in a script or something... But I don't think it's helpful to not tell users that there is something wrong when there is something wrong (though I admit this error isn't particularly clear about what is wrong).

[jsoref]

Somewhere there are places that suggest running the plug-in installer as root. It should ideally be a command that figures out the right user. At worst, it should include explanatory text explaining how a user should figure out the right answer.

Beyond that, as this seems to be a common problem, if the app runs as root, it should check ownership of the files and at the very least warn about the risk, ideally refusing to write over files owned by a different user.

As to using standard error, that would be a moderate improvement. But please keep in mind that you, a very experienced user, totally missed the version information in the output. As such, that really isn't sufficient to help users. I think it's reasonable to argue that it is necessary, just not sufficient.

[jsoref]

I've sent and had PRs merged in the past. If someone can suggest commands/pages/branches, I could probably write one sooner. Otherwise it'll probably take me a while.

[spalger]

Starting in 7.2 we will error if Kibana is run as root, as it should never be necessary, thanks to #21563.

I've also done a search through the docs to find references to sudo and don't spot any in relation to plugin installation. If you have links it'd be easier to track those instances down and fix things.

As for command/page/branch suggestions, not sure what type of suggestions you're looking for. Suggestions for editing the docs?

building the docs: https://github.com/elastic/kibana/blob/master/CONTRIBUTING.md#writing-documentation
source files: https://github.com/elastic/kibana/tree/master/docs, or click the "edit" link at the top of the related doc page to find out which file that doc is in:

links to =>

[jbudz]

This is also happening for other bins, including the keystore.

I believe the service file will pull the correct path in via /etc/default/kibana - but any direct use won't.

[jbudz]

babel/register was removed starting in 7.10 with #79379 so babel writes should no longer be a source of permission errors. Closing this out