Grpc-go: Error happens when a program imports grpc more than twice

[mitake]

The below error happened when I build a program that imports grpc twice (indirectly).

panic: http: multiple registrations for /debug/requests

goroutine 1 [running]:
net/http.(*ServeMux).Handle(0xc820013530, 0xd89360, 0xf, 0x7f99e074c090, 0xf0cc00)
       /usr/local/go/src/net/http/server.go:1715 +0x292
net/http.(*ServeMux).HandleFunc(0xc820013530, 0xd89360, 0xf, 0xf0cc00)
       /usr/local/go/src/net/http/server.go:1744 +0x6a
net/http.HandleFunc(0xd89360, 0xf, 0xf0cc00)
       /usr/local/go/src/net/http/server.go:1756 +0x41
golang.org/x/net/trace.init.1()
       /home/mitake/gopath/src/golang.org/x/net/trace/trace.go:118 +0x38
golang.org/x/net/trace.init()
       /home/mitake/gopath/src/golang.org/x/net/trace/trace.go:898 +0x5ad
google.golang.org/grpc.init()
       /home/mitake/gopath/src/google.golang.org/grpc/trace.go:120 +0x5b
github.com/osrg/gobgp/api.init()
       /home/mitake/gopath/src/github.com/osrg/gobgp/api/gobgp.pb.go:3207 +0x5b
github.com/osrg/gobgp/openswitch.init()
       /home/mitake/gopath/src/github.com/osrg/gobgp/openswitch/openswitch.go:314 +0x45
main.init()
       /home/mitake/gopath/src/github.com/osrg/gobgp/gobgpd/main.go:238 +0x4f

goroutine 17 [syscall, locked to thread]:
runtime.goexit()
       /usr/local/go/src/runtime/asm_amd64.s:1696 +0x1

The root cause of the error seems to be the module golang.org/x/net/trace. Its init() registers a handler to the same URL (e.g. /debug/requesets). Therefore importing the module more than twice causes the above panic.

I'm not sure here is a suitable place for reporting the problem. I'd like to hear gRPC developers' opinion. Should I go to the issue tracker of golang? Or is a workaround for this problem known?

[dsymonds]

There's something going wrong on your end. The likely problem is that the trace package is being imported in two different ways. Or do you have it vendored? Or other code registering on /debug/requests?

[zellyn]

This exact thing happened to me, and it was as @dsymonds describes.

Not that our environments are likely to be exactly the same, but for reference: We're still using godep and path rewriting. I had to track down the non-Godep-folder import of x/net/trace that goimports had inserted into my code somewhere. The simplest way was for me to rm -rf $GOPATH/src/golang.org/x/net and go build ./... everything, find the build error, then fix that import to use the Godep'd import.

[mitake]

@dsymonds @zellyn thanks a lot for your reply. I agree that this problem isn't gRPC specific one. So closing it.

@zellyn so are you using your own modified (not upstream) version of x/net/trace?

[zellyn]

@mitake nope - we just vendor everything we use.

[mitake]

@zellyn thanks, I'll try the building again.

[immesys]

Please reopen this, this is a problem. I have an application that exposes a grpc service, and the application happens to use etcd which happens to also use grpc. I can't change how etcd vendors grpc, so how do I solve this problem?

[menghanl]

@immesys This is a dependency management problem, not something that we can solve within gRPC.

Please look into the dependency management tool you use to see how to avoid double import.
The discussions in etcd repo (https://github.com/coreos/etcd/pull/9155, https://github.com/coreos/etcd/pull/9240) might help.

[sdboyer-stripe]

@immesys using dep will fix the issue for you - it'll ensure there's only one copy in vendor.