search

sous-chefs / consul

Development repository for the consul cookbook
https://supermarket.chef.io/cookbooks/consul
Apache License 2.0
192 stars 244 forks source link

upstart: consul info hangs with custom client_addr #355

Closed barshashrest closed 7 years ago

barshashrest commented 8 years ago

In the init script /etc/init/consul.conf created by this template, there is a post-script script:

post-start script
  while ! /opt/consul/0.7.0/consul info ; do sleep 1; done
end script

This runs consul info by default with rpc address localhost. However this is problematic when we provide a custom client_addr (for example I want to specify the instance IP itself rather than localhost or 0.0.0.0). Because of this, in the logs, it keeps spitting out the error message Error connecting to Consul agent: dial tcp 127.0.0.1:8400: getsockopt: connection refused and the script never stops running and continues sleeping for 1 second.

If there could be a logic added in /etc/init/consul.conf for consul info to be run using the -rpc-addr= parameter when client_addr is not localhost or 0.0.0.0, this could be resolved.

The template for /etc/init/consul.conf is here

Thanks!

johnbellone commented 8 years ago

This is definitely undesirable - I am assuming that you have changed the client_addr parameter inside of the configuration resource? I would expect that it reads that file prior to running anything.

barshashrest commented 8 years ago

Yeah I am using the client_addr attribute. I think that the upstart.service.erb template needs to be modified at the specified line because consul info by default runs on localhost (same is the case with any other consul commands like consul members). So changing that line to consul info -rpc-addr=<client_addr> would be ideal in the template whenever client_addr is specified to be something other than localhost or '0.0.0.0'.

johnbellone commented 7 years ago

Does consul info not read from the configuration file? It would be kind of a pain to have to wire in command-line parameters into templates... we've just relied on the fact that commands read from a default location for the configuration.

predominant commented 7 years ago

@johnbellone Further to this, the post-start loop at the end of the upstart really should be placed in any dependant service pre-start.

The condition for consul to start is not a successful consul info return result. It is a pre-start condition for any dependant services, though. Consul should start even if consul info fails, as it retries its cluster/master connection as part of normal service operation.

legal90 commented 7 years ago

That issue was fixed by https://github.com/johnbellone/consul-cookbook/pull/434/commits/25090275a3cc9132236fb83cb583d6a60b5ac62f in the scope of #434 post-start hook was just removed.

lock[bot] commented 4 years ago

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.