coredns: Debug plugin option ignored in CoreDNS 1.8.4
What happened: When CoreDNS version bumped up from 1.6.1 to 1.8.4, debug outputs are not written to the output, although debug option is present in the configuration.
What you expected to happen: Debug outputs written to the output when debug plugin is active.
How to reproduce it (as minimally and precisely as possible):
We’ve experienced it with dig @localhost -p 40000 google.com
when logging debug outputs with zipkin trace ids in internal logging plugin, but it should be reproducible with any debug logging using coredns@1.8.4/plugin/pkg/log/plugin.go debug() or debugf() function.
Anything else we need to know?:
coredns@1.8.4/plugin/pkg/log/plugin.go debug() or debugf() functions use if !D.Value()
to ignore debug outputs when debug plugin is not active. Having debug plugin active in Corefile for several ports in the same configuration block is not reflected, D.Value() == false (see Corefile example). Seems like the configuration is not being read properly.
Environment:
- the version of CoreDNS: 1.8.4
- Corefile:
.:8000 { health pprof }
.:40000, .:40001, .:40002, .:40003 { error_trace debug forward . 64.6.64.6 8.8.8.8 log . “plugin/log: [{>id}] ‘{type} {class} {name} {proto}:{port} {size} {>do} {>bufsize}’ {rcode} {>rflags} {rsize} {duration}” ready any }
About this issue
- Original URL
- State: closed
- Created 3 years ago
- Reactions: 2
- Comments: 16 (16 by maintainers)
THANKS Chris, that’s it! We have github.com/coredns/caddy v1.1.1 referred explicitly in go.mod. When I removed it and run
go mod tidy
, v1.1.0 has been added and the application logs debug messages like a charm 😃 Seems that #4593 will have to be polished a little bit before merge.Suppose: Corefile contains configuration block activating
debug
and is defined for ports .:40000, .:40001, .:40002Now what happens in the code:
config.Debug = true
if j > 0 {continue}
allows to call it only for the first server in the group; if we have configuration block for several ports e.g. .:40000, .:40001, .:40002, the setup function is called only for the first server (.:40000); that means, config.Debug for .:40001 and .:40002 stays FALSElog.D.Set()
orlog.D.Clear()
based on the specific server config; so it calllog.D.Set()
for .:40000 and follows withlog.D.Clear()
for .:40001 and thenlog.D.Clear()
for .:40002=> so finally the debug flag in log is FALSE, although it should be TRUE