-
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
'Service does not exist' should not be fatal #769
Comments
Same here, it happens often on rebooting the cluster (which i'm doing due to testing) Current status: Can't start any consul agent, datacenter is currently down. consul data-dir most likely needs to be erased and kv/store needs to be recreated from scratch.. |
Thanks for the report, tagging as a bug! |
Great. How tricky is this to fix? |
I don't think this one will be too hard to fix. I'll take a look at it soon, although you'd have to build from master to get the fix since we have no release dates planned yet. |
sure. i can build it and distribute it from my own repo as long as there's something that works. :) |
Fixed by 04a2fae. We now warn and purge the erroneous check. Thanks! |
Sweet, thanks Ryan On Wed, Mar 11, 2015, 18:27 Ryan Uber notifications@github.com wrote:
|
Awesome, way faster than i thought possible ;) |
Mm, I think this is still happening?
I defined the service in a check.
Running
|
Hi @tonglil, Is this check inside of a config file? This fix is only to purge health checks which were submitted from the REST API, and whose services no longer exist when Consul is restarted. If the check is defined in a configuration file, you have to remove the check or the config file which contains it. Hope that helps. |
Ah gotcha, thanks for the clarification @ryanuber. Do you know what the reasoning is for making it fatal for config files? |
No problem. I think it was mainly just the most logical course of action when a check is attempted to register against an unknown service. You would otherwise get a running Consul agent without the check or the service you specified, which seems rather unexpected. Let me know if I missed anything! |
AKS seems to have a bug with 1.19+ and hostPorts: Azure/AKS#2070
Occasionally we have a server that crashes or is rebooted un-cleanly. On restart consul dies with an error:
This requires manual intervention to remove the service from the consul data-dir and restart the services.
This error should not be fatal, and should simply result in the service not being available in the catalog.
An additional note: In this case the services are registered using the HTTP API not the config files.
The text was updated successfully, but these errors were encountered: