go: net/rpc: server.Register() should not internally log by default

What version of Go are you using (go version)?

$ go version
go version go1.8 linux/amd64

What operating system and processor architecture are you using (go env)?

$ go env
GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/ppai/work"
GORACE=""
GOROOT="/home/ppai/go"
GOTOOLDIR="/home/ppai/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
CC="gcc"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build142468001=/tmp/go-build -gno-record-gcc-switches"
CXX="g++"
CGO_ENABLED="1"
PKG_CONFIG="pkg-config"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"

What did you do?

https://play.golang.org/p/Y5tF3ruvTw

From the net/rpc source:


// suitableMethods returns suitable Rpc methods of typ, it will report
// error using log if reportErr is true.
func suitableMethods(typ reflect.Type, reportErr bool) map[string]*methodType {
...
...
		if mtype.NumIn() != 3 {
   				if reportErr {
   					log.Println("method", mname, "has wrong number of ins:", mtype.NumIn())
   				}
   				continue
   		}

The unexported caller sets reportErr to true:

func (server *Server) register(rcvr interface{}, name string, useName bool) error {
...
...
	// Install the methods
   	s.method = suitableMethods(s.typ, true)

What did you expect to see?

It is not uncommon for a type to contain methods that do not conform to the method signatures required by net/rpc. The net/rpc should not log these benign log messages by default when it finds such methods. There should be a way to turn this off or ignore it. It should be logged only if a flag or variable is set.

What did you see instead?

2009/11/10 23:00:00 method Name has wrong number of ins: 1

About this issue

  • Original URL
  • State: closed
  • Created 7 years ago
  • Reactions: 3
  • Comments: 15 (9 by maintainers)

Commits related to this issue

Most upvoted comments

I found this issue because I just ran into this myself. I have a type which I want to expose as an RPC endpoint, but it has additional exported methods. The mandatory emission of logs is bad ergonomics here, and goes against the documentation, which says:

Only methods that satisfy these criteria will be made available for remote access; other methods will be ignored: […] list of criteria

Emitting a log is not entirely ignoring other methods.

From this issue it sounds like @robpike was for reverting the mandatory logging, but then the issue got auto-closed after only the error message part changed.

I’m reopening the issue, and will be happy to implement the change. Are there any objections?

@minux