Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

elasticsearch create error #49

Closed
qmapDL opened this issue Nov 21, 2018 · 7 comments
Closed

elasticsearch create error #49

qmapDL opened this issue Nov 21, 2018 · 7 comments

Comments

@qmapDL
Copy link

qmapDL commented Nov 21, 2018

I'm trying to run the portland example project but can't get elastisearch to work: it seems to start fine but then it seems it didn't come up. Any pointers?

qmap@pelias:/opt/pelias/projects/portland-metro$ sudo pelias elastic start
Recreating pelias_elasticsearch ... 
Recreating pelias_elasticsearch ... done
qmap@pelias:/opt/pelias/projects/portland-metro$ sudo pelias elastic wait
waiting for elasticsearch service to come up
..............................
Elasticsearch did not come up, check configuration
qmap@pelias:/opt/pelias/projects/portland-metro$ sudo pelias elastic create
Elasticsearch ERROR: 2018-11-21T16:36:32Z
  Error: Request error, retrying
  GET http://elasticsearch:9200/_nodes => getaddrinfo ENOTFOUND elasticsearch elasticsearch:9200
      at Log.error (/code/pelias/schema/node_modules/elasticsearch/src/lib/log.js:226:56)
      at checkRespForFailure (/code/pelias/schema/node_modules/elasticsearch/src/lib/transport.js:259:18)
      at HttpConnector.<anonymous> (/code/pelias/schema/node_modules/elasticsearch/src/lib/connectors/http.js:163:7)
      at ClientRequest.wrapper (/code/pelias/schema/node_modules/lodash/lodash.js:4935:19)
      at ClientRequest.emit (events.js:182:13)
      at Socket.socketErrorListener (_http_client.js:391:9)
      at Socket.emit (events.js:182:13)
      at emitErrorNT (internal/streams/destroy.js:82:8)
      at emitErrorAndCloseNT (internal/streams/destroy.js:50:3)
      at process._tickCallback (internal/process/next_tick.js:63:19)

Elasticsearch WARNING: 2018-11-21T16:36:32Z
  Unable to revive connection: http://elasticsearch:9200/

Elasticsearch WARNING: 2018-11-21T16:36:32Z
  No living connections

{ Error: No Living connections
    at sendReqWithConnection (/code/pelias/schema/node_modules/elasticsearch/src/lib/transport.js:226:15)
    at next (/code/pelias/schema/node_modules/elasticsearch/src/lib/connection_pool.js:214:7)
    at process._tickCallback (internal/process/next_tick.js:61:11) message: 'No Living connections' }
please install mandatory plugins before continuing.
@missinglink
Copy link
Member

missinglink commented Nov 21, 2018

Interesting.. the relevant error message here is Elasticsearch did not come up, check configuration.

I hope the step pelias elastic wait returned a non-zero status code.

@orangejulius, this user is running pelias commands as root using sudo, I vaguely recall that has caused issues in the past?

Can you please try running the command again as a non-root user.

You should not proceed with the other commands until the elastic wait command is successful.

@missinglink
Copy link
Member

Can you please post a copy of your .env file and the elasticsearch section of your docker-compose.yml file?

@missinglink
Copy link
Member

Two other things to try:

  • Manually check that elasticsearch is running by opening localhost:9200 in your browser
  • If it's failing for a configuration reason then you can check the logs, I put a section in the readme about that.

@missinglink
Copy link
Member

I suspect the issue is to do with the file ownership permissions on your elasticsearch data directory not being writable by the user you're running the script as.

@qmapDL
Copy link
Author

qmapDL commented Nov 22, 2018

setting data_dir permissions to 777 and running pelias as non root user seems to solve the issue

@missinglink
Copy link
Member

I'm closing this issue as it resolved then reported issue.

We discussed today a solution to mitigate these permission errors in the future so hopefully it's no longer an issue for anyone after we land that PR (eta next week).

@orangejulius
Copy link
Member

Hey @qmapDL,
The improvement in #55 should mean chmod 777 is no longer required. If you get a chance to test out that PR, let me know how it looks.

steps to test:

  1. pelias elastic stop to kill the elasticsearch container
  2. rm -rf $DATA_DIR/elasticsearch to clear out the old ES data dir and ensure a clean setup for testing
  3. pelias elastic start. Elasticsearch should now come up, and $DATA_DIR/elasticsearch should have permissions that allow it to be read by UID 1000 (even if you ran the pelias helper script as root)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants