1

Elastic's Enterprise Search Installation Guide goes as far as starting the process locally - which is obviously not very stable.

When installed from a .deb or .rpm, a service is actually set up and ready to use but unfortunately, it doesn't seem to be working!?

When I start the service, all I can see is:

$ systemctl status enterprise-search

● enterprise-search.service - Elastic Enterprise Search
     Loaded: loaded (/lib/systemd/system/enterprise-search.service; enabled; vendor preset: enabled)
     Active: active (running) since Sat 2021-07-10 15:26:17 UTC; 3s ago
       Docs: https://www.elastic.co/guide/en/enterprise-search/current/index.html
   Main PID: 9144 (java)
      Tasks: 19 (limit: 9536)
     Memory: 209.0M
     CGroup: /system.slice/enterprise-search.service
             └─9144 java -cp /usr/share/enterprise-search/lib/war/lib/jruby-stdlib-9.2.13.0.jar:/usr/share/enterprise-search/lib/war/lib/jruby-core-9.2.13.0-complete.jar -Djruby.cli.warning.level=NIL -Djava.a>

Jul 10 15:26:17 ip-172-31 systemd[1]: Started Elastic Enterprise Search.
Jul 10 15:26:17 ip-172-31 enterprise-search[9144]: Found java executable in PATH
Jul 10 15:26:18 ip-172-31 enterprise-search[9144]: Java version detected: 11.0.11 (major version: 11)
Jul 10 15:26:18 ip-172-31 enterprise-search[9144]: Enterprise Search is starting...
Jul 10 15:26:18 ip-172-31 enterprise-search[9144]: Logs can be found in the location configured via the 'log_directory' setting (typically /var/log/enterprise-search)

But the logs don't have any new entries and nothing's listening on the defined port. Whereas starting the search just as a normal process as

sudo /usr/share/enterprise-search/bin/enterprise-search

Works perfectly fine.

nohup is also not helpful, the process stops very shortly after it starts, exactly as seen in this post

I have added a comment to that thread but as it was already marked as solved I don't expect to see an answer. The solution provided did not work for me.

Any suggestions?

UPDATE

journalctl -u enterprise-search.service reveals that the service is currently failing due to permission issues to its own log.

e.g.

Jul 11 16:57:53 ip-172-31 enterprise-search[284346]: Unexpected exception while running Enterprise Search:
Jul 11 16:57:53 ip-172-31 enterprise-search[284346]: Error: Permission denied - /var/log/enterprise-search/stats.log at org/jruby/RubyIO.java:1237:in `sysopen'

Changing the owner to enterprise-search for the following:

app-server.log
connectors.log
filebeat
stats.log
system.log
worker.log

resolves the issue temporarily but it will resourface when the logs get rotated.

The initialisation now fails with:

enterprise-search[286929]: Unexpected exception while running Enterprise Search:
enterprise-search[286929]: NoMethodError: undefined method `join' for nil:NilClass
enterprise-search[286929]:     run! at /usr/share/enterprise-search/lib/war/shared_togo/lib/shared_togo/cli.class:115
enterprise-search[286929]:   <main> at bin/enterprise-search-internal:15
systemd[1]: enterprise-search.service: Main process exited, code=exited, status=1/FAILURE
systemd[1]: enterprise-search.service: Failed with result 'exit-code'.

I'm guessing this will still be related to privileges but I'm a bit stuck as to what else I have to change. I also have no clue how to make sure that the logs stay with the enterprise-search user on rotation.

5
  • Active: active (running) so this service should be up and running
    – djdomi
    Jul 11, 2021 at 9:59
  • It should. But it isn't.
    – RekaB
    Jul 11, 2021 at 14:15
  • /var/log/enterprise-search is empty? Or is a reason why you hide the logs? did you tried /etc/init.d/elas... | tail -f /var/log/syslog and can you please decide if you use redhead (RPM) or debian (deb) based system?
    – djdomi
    Jul 11, 2021 at 15:09
  • Yes, the logs are empty - the service doesn't start. Using journalctl -u enterprise-search.service reveals that the service can't start because it has no permissions for its own log.
    – RekaB
    Jul 11, 2021 at 16:29
  • why you not update your question with this relevant information ls?
    – djdomi
    Jul 11, 2021 at 19:58

1 Answer 1

1

The final solution for this is in the update of the question: changing the owners of the log files to enterprise-search resolved the issue. The final error mentioned above was related to the elasticsearch process crashing as the enterprise-search was starting up. Rebooting the server solved all the issues and everything is working fine now. Logs are rotating also.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .