-
Notifications
You must be signed in to change notification settings - Fork 4.4k
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
Feature request: Notify systemd after agent has joined cluster #2121
Labels
theme/operator-usability
Replaces UX. Anything related to making things easier for the practitioner
type/enhancement
Proposed improvement or new feature
Comments
slackpad
added
the
theme/operator-usability
Replaces UX. Anything related to making things easier for the practitioner
label
May 25, 2017
Any news on when will this become available? |
I'll pick this one up after the next release. |
magiconair
added a commit
that referenced
this issue
Jun 20, 2017
This patch adds support for notifying systemd via the NOTIFY_SOCKET by sending 'READY=1' to the socket after a successful JoinLAN. Fixes #2121
magiconair
added a commit
that referenced
this issue
Jun 21, 2017
This patch adds support for notifying systemd via the NOTIFY_SOCKET by sending 'READY=1' to the socket after a successful JoinLAN. Fixes #2121
magiconair
added a commit
that referenced
this issue
Jun 21, 2017
This patch adds support for notifying systemd via the NOTIFY_SOCKET by sending 'READY=1' to the socket after a successful JoinLAN. Fixes #2121
nathanejohnson
added a commit
to myENA/consul
that referenced
this issue
Apr 19, 2019
hashicorp#2121 https://www.freedesktop.org/software/systemd/man/systemd.service.html When set to notify, systemd will not attempt to start any dependent services until after consul sends the notify signal. This is useful in cases where there services that rely on the local consul agent to be up and functional before they can start. The default is simple, which will immediately mark the service as up and functioning even if consul has not yet joined the cluster and has started listening for connnections.
banks
pushed a commit
that referenced
this issue
May 13, 2019
…y. (#5689) #2121 https://www.freedesktop.org/software/systemd/man/systemd.service.html When set to notify, systemd will not attempt to start any dependent services until after consul sends the notify signal. This is useful in cases where there services that rely on the local consul agent to be up and functional before they can start. The default is simple, which will immediately mark the service as up and functioning even if consul has not yet joined the cluster and has started listening for connnections.
3 tasks
This was referenced Jun 2, 2023
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
theme/operator-usability
Replaces UX. Anything related to making things easier for the practitioner
type/enhancement
Proposed improvement or new feature
On a system where a client or server needs to use the Consul agent, one would naturally declare a dependency on the Consul agent's startup on its own. That way it can arrange for Consul to be available before it starts up.
However, a predicate satisfied solely on Consul starting is insufficient, because a service manager will consider Consul up from the moment it successfully launches. There then exists a race between Consul joining the cluster and the dependent service launching. If the dependent service starts too soon, it will fail to resolve Consul services and look up keys.
So, if systemd is managing system startup, it would be useful for Consul to emit an event via sd_notify() after the agent has successfully joined the cluster. That way one could set Consul's
type
in the Unit file tonotify
and defer starting dependent services until Consul is truly ready to accept queries.Some useful code may be found at https://github.com/coreos/go-systemd/blob/7b2428fec40033549c68f54e26e89e7ca9a9ce31/daemon/sdnotify.go
The text was updated successfully, but these errors were encountered: