upstart: consul info hangs with custom client_addr

[barshashrest]

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=<client_addr:8400> 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]

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]

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]

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]

@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]

That issue was fixed by 2509027 in the scope of #434
post-start hook was just removed.

[lock]

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.