Systemd issue with boot order.

[Kraeutergarten]

Since the current Type of the service is "simple" systemd proceed immediately with the "depending" units.

See: https://www.freedesktop.org/software/systemd/man/systemd.service.html -> Options -> Type

Since elasticsearch needs some time to start, there are some problems with other software, which needs elasticsearch being up.

I hope you understand the problem and I'm sorry for my bad english.

[nik9000]

That makes sense! You'd like the service not to be "up" until it is
actually ready to take requests.

On Sep 23, 2016 5:39 PM, "Nosxxx" notifications@github.com wrote:

Since the current Type of the service is "simple" systemd proceed
immediately with the "depending" units.

See: https://www.freedesktop.org/software/systemd/man/systemd.service.html
-> Options -> Type

Since elasticsearch needs some time to start, there are some problems with
other software, which needs elasticsearch being up.

I hope you understand the problem and I'm sorry for my bad english.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#20647, or mute the
thread
https://github.com/notifications/unsubscribe-auth/AANLooGnXS7oBvMQn55dAgf9_H_mpbASks5qtEcagaJpZM4KFaoY
.

[Kraeutergarten]

You'd like the service not to be "up" until it is actually ready to take requests.

That's exactly what I mean. Thank you.

[tlrx]

I understand the issue but I don't see what makes sense to you @nik9000 : are you in favour of moving away from the simple type?

[nik9000]

I know you can move away from it to get features like this but I don't know more than that.

[userappgate]

You need to use Type=forking, and make elasticsearch do a fork() after it's ready, to signal that it's ready. This has been the way of unix demons for decades.

So something like

//Some initialization code
create socket

daemon() // Basically a fork, it's a libc call

the rest of the stuff

So systemd, after the fork happened, knows that the socket is ready and subsequent units can be started and they will find the socket.

Even if the socket isn't ready to reply to data, it's fine that they can connect, send the request and get stuck for a bit, waiting the answer.

[userappgate]

This isn't for systemd only, it's the normal way daemons are supposed to work on unix.

[marknelsonengineer]

Wow, I can't believe this issue hasn't generated more comments... My 2 cents worth...

1. This is a big deal. Elasticsearch is a production quality daemon and, while systemd integration is mundane, it's the future. Leveraging systemd is a good investment.
2. I'd recommend we get Elasticsearch to use either dbus or sd_notify... This way, we can use systemd's watchdog monitoring and we can configure Kibana (which also needs a systemd script) to literally start after Elastisearch is ready for business (assuming they are running on the same box).

If I can get some insight from one of the more experienced maintainers, I'd be happy to volunteer to look into adding this capability.

[williamrandolph]

We, and by "we" I mean @jasontedor, changed the systemd service type to notify in PR #44673. I will try to verify that this change fixes the issue reported here.

[jasontedor]

@williamrandolph Thanks for bringing this issue to my attention, I wasn’t aware of it. Yes, the work in #44673 should close this issue out indeed.

@marknelsonengineer Sorry that this issue and your comment was neglected for so long. We integrated Elasticsearch with systemd via sd_notify indeed in #44673. That functionality will be available in the 7.4.0 release.

[williamrandolph]

I'm closing this issue due to the successful merge of #44673.

[ltworf]

Thanks for making this only included in the packages and not archives.

Does this mean that if I download an elasticsearch .tar.gz this change will not be included in it?