Provide a hint to check the logs if the service does not start

[markwalkom]

I have noticed an increase in users not able to start Elasticsearch after installation, and they are only providing the response from the service start command. Is it possible to have Elasticsearch return a message like "Please check your Elasticsearch logs for more information." to the output to give people a hint on what to do next. I feel that it'd help reduce a lot of friction and give users guidance.

Here's some recent topics where it would have helped;
https://discuss.elastic.co/t/elasticsearch-service-failed-to-start-on-centos/247034/
https://discuss.elastic.co/t/es-7-9-doesnt-start/246908
https://discuss.elastic.co/t/elastic-search-failed-to-start/246845

[elasticmachine]

Pinging @elastic/es-distributed (:Distributed/Allocation)

[elasticmachine]

Pinging @elastic/es-core-infra (:Core/Infra/Core)

[rjernst]

This should be possible. I've marked this for discussion, but I believe this is a trivial change. We just need to write a message with the ES log path to stdout, which will get picked up by journald/systemd.

[jasontedor]

Relates #47208.

[pugnascotia]

We discussed it, and it seem entirely reasonable.

[pugnascotia]

So it turns out that we do try to print a pointer to the logs. We only do this if Elasticsearch managed to get as far as configuring logging, because there's no point in directing a user to the logs if ES can't have written anything to them.

However, we actually need more exception handling here since elasticsearch.main(...) only catches a couple of expected exception, and lets anything else propagate, and that stops us printing the log message.

[pugnascotia]

Hmm, there's also ElasticsearchUncaughtExceptionHandler, which actually writes out the exception details to stderr. That may be a more natural place to add a pointer to the logs?

[rjernst]

@pugnascotia It seems we have a bit of overlap between the uncaught exception handler, and the main method return you pointed to above. The uncaught exception handler directly exits, which causes us not to invoke the above. I wonder if we should consolidate these in some way (the exiting) so that when we are prepared to exit, we print the message pointing at the logs, and then use the halt mechanism uncaught exception handler uses now.