Feature request: Notify systemd after agent has joined cluster #2121
Assignees
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
|
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
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
typein the Unit file tonotifyand 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: