Consul keeps dialling home even though disable_update_check is set to true

[kesterriley]

If you have a question, please direct it to the
consul mailing list if it hasn't been
addressed in either the FAQ or in one
of the Consul Guides.

When filing a bug, please include the following:

consul version for both Client and Server

Client: Consul v0.9.3
Server: Consul v0.9.3

consul info for both Client and Server

Client:

[Client consul info here]

agent:
	check_monitors = 4
	check_ttls = 0
	checks = 5
	services = 1
build:
	prerelease = 
	revision = 112c060
	version = 0.9.3
consul:
	known_servers = 3
	server = false
runtime:
	arch = amd64
	cpu_count = 2
	goroutines = 46
	max_procs = 2
	os = linux
	version = go1.9
serf_lan:
	coordinate_resets = 0
	encrypted = false
	event_queue = 0
	event_time = 5
	failed = 0
	health_score = 0
	intent_queue = 0
	left = 0
	member_time = 522
	members = 17
	query_queue = 0
	query_time = 1

Server:

[Server consagent: check_monitors = 4 check_ttls = 0 checks = 4 services = 0 build: prerelease = revision = 112c060 version = 0.9.3 consul: known_servers = 3 server = false runtime: arch = amd64 cpu_count = 4 goroutines = 46 max_procs = 2 os = linux version = go1.9 serf_lan: coordinate_resets = 0 encrypted = false event_queue = 0 event_time = 5 failed = 0 health_score = 0 intent_queue = 0 left = 0 member_time = 522 members = 17 query_queue = 0 ul info here]

Operating system and Environment details

Linux rhel73 3.10.0-514.el7.x86_64 #1 SMP Wed Oct 19 11:24:13 EDT 2016 x86_64 x86_64 x86_64 GNU/Linux

Description of the Issue (and unexpected/desired result)

Consul keeps trying to dial home:

Nov 6 12:50:21 rhel73appservermm01 consul[4491]: dns: all resolvers failed for {checkpoint-api.hashicorp.com.specsavers.local. 28 1} from client 127.0.0.1:51999 (udp)

Even though all my servers and clients have the:

"disable_update_check": true,    

line set in the config....

{
"bootstrap": false,
"server": false,
"datacenter": "dc1",
"data_dir": "/var/consul",
"recursors" : [ "10.238.130.4" ],
"ports" : {
"dns" : 53
},
"log_level": "err",
"enable_syslog": true,
"advertise_addr": "192.34.88.153",
"client_addr": "0.0.0.0",
"enable_script_checks": true,
"disable_update_check": true,
"retry_join": ["192.34.88.101","192.34.88.102","192.34.88.103"]
}

[slackpad]

Hi @kesterriley that error message is actually from Consul's DNS client, so something is trying to look that up using Consul's DNS interface (that could be Consul itself, depending on how the box is configured). I tried this option under 0.9.3 and 1.0.0 and it looks like it's working properly to disable the checkpoint client. Is it possible that there's some other HashiCorp thing running on that box alongside Consul?

[kesterriley]

@slackpad thanks for your reply.

There is nothing else HashiCorp running on these servers, if there are any commands or log files you would like. please let me know.

[slackpad]

Hmm - can you please post a gist with the output of /v1/agent/self?pretty so we can confirm things are configured as you expect?

[pearkes]

Given we haven't heard anything based on our suggestions/questions above I'm going to close this issue, but I encourage you to comment and we can re-open it if you want to pick this up again.

Alternatively, if things have changed dramatically, feel free to create a new issue or PR.

[hvindin]

I'm not sure if i should open a new issue for this but we're seeing consul try to call back to hashicorp.com deapite having disable_update_check: true in our config.

This is happening on 1.1.0+ent and 1.0.7+ent.

Let me know if you want me to open a new issue or provide more details here.

[mkeeler]

@hvindin The code for doing the disable seems to be working for me in 1.1.0+ent. Then again all I am doing is passing

consul agent --config-file=disable.json -dev

With disable.json being:

{
   "disable_update_check" : true
}

Is there any more information regarding how you are running/configuring consul you could provide?