You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Using the route53 plugin (others like azure and clouddns probably as well), can spawn an additional concurrent refresh loop for every USR1 signal received.
I added a debug line to the route53 updateZones function:
@@ -238,6 +242,7 @@ func updateZoneFromRRS(rrs *route53.ResourceRecordSet, z *file.Zone) error {
func (h *Route53) updateZones(ctx context.Context) error {
errc := make(chan error)
defer close(errc)
+ fmt.Println(time.Now().String(), "running refresh loop: ", h.zones)
for zName, z := range h.zones {
go func(zName string, z []*zone) {
var err error
A loop is started when the server is started. I let it it refresh once normal, which happens at 5 minutes, then shortly there after I sent a USR1 signal. Another refresh occurs, and then approximately 4.5 minutes and 5 minutes after that you can see both loops refresh again.
What you expected to happen:
USR1 should only refresh configuration information and clean-up any existing loops to get external data that a plugin may have open.
How to reproduce it (as minimally and precisely as possible):
Configure a route53 plugin to get zone from Route 53.
Add a debugging print statement.
Run CoreDNS and observe the logging statements.
Send USR1 as many times as you like to observe n loops occurring in the background.
Anything else we need to know?:
There was an underlying problem with Caddy a while ago that seemed to be related to the issue. #2396 But CoreDNS now uses the fixed version of Caddy and the problem still exists. I'm not really sure how to debug/fix further. I do note that this log statement is never printed: https://github.com/coredns/coredns/blob/master/plugin/route53/route53.go#L90. So I would imagine the context's Done channel is never closing.
What happened:
Using the
route53
plugin (others likeazure
andclouddns
probably as well), can spawn an additional concurrent refresh loop for every USR1 signal received.I added a debug line to the route53 updateZones function:
My debugging output is recorded here w/ 3 server blocks configured with the route53 plugin and configured for a 5 minute refresh interval. https://gist.github.com/mattlqx/7e8126c42a02cf6caa0982adb8fb8207
A loop is started when the server is started. I let it it refresh once normal, which happens at 5 minutes, then shortly there after I sent a USR1 signal. Another refresh occurs, and then approximately 4.5 minutes and 5 minutes after that you can see both loops refresh again.
What you expected to happen:
USR1 should only refresh configuration information and clean-up any existing loops to get external data that a plugin may have open.
How to reproduce it (as minimally and precisely as possible):
Configure a route53 plugin to get zone from Route 53.
Add a debugging print statement.
Run CoreDNS and observe the logging statements.
Send USR1 as many times as you like to observe n loops occurring in the background.
Anything else we need to know?:
There was an underlying problem with Caddy a while ago that seemed to be related to the issue. #2396 But CoreDNS now uses the fixed version of Caddy and the problem still exists. I'm not really sure how to debug/fix further. I do note that this log statement is never printed: https://github.com/coredns/coredns/blob/master/plugin/route53/route53.go#L90. So I would imagine the context's Done channel is never closing.
Environment:
cat /etc/os-release
): PRETTY_NAME="Debian GNU/Linux 10 (buster)" (Golang 1.14.1 docker container)The text was updated successfully, but these errors were encountered: