Go version
go version go1.16 x86/amd64
Output of go env
in your module/workspace:
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/root/.cache/go-build"
GOENV="/root/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/root/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/root/go"
GOPRIVATE=""
GOPROXY="direct"
GOROOT="/usr/lib/golang"
GOSUMDB="off"
GOTMPDIR=""
GOTOOLDIR="/usr/lib/golang/pkg/tool/linux_amd64"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build417955797=/tmp/go-build -gno-record-gcc-switches"
What did you do?
// Start initializes and starts components in dockerService.
func (ds *dockerService) Start() error {
....
// start the server in goroutine
go func() {
if err := ds.streamingServer.Start(true); err != nil {
klog.ErrorS(err, "Streaming server stopped unexpectedly")
os.Exit(1)
}
}()
....
}
func (s *server) Start() error {
listener, err := net.Listen("tcp", s.config.Addr)
if err != nil {
return err
}
return s.server.Serve(listener)
}
What did you see happen?
The server listens a random tcp port
after running a few days, the listen port is gone(can not find by netstat) and the fd socket is closed, but the process is still running and the goroutine still exists
What did you expect to see?
- the s.server.Serve(listener) should return immediately after the socket fd closed
- the socket fd should not be closed, there is no close() be called in the code
Comment From: gabyhelp
Similar Issues
- net: TCP server did NOT Close Conn when I close connection #29989
- net/http: Server still handling new connections after Close (or Shutdown) returns #36093
- net: Listener.Close() does not fully stop the server when Accept()'ing at the same time #22502
- net/http: something about semantics of Server.Close #17880
- net/http: Server.Close does defer Lock #17878
- net/http: TCP connection is not closed after http client makes a https request via a http proxy server which doesn't response #28012
- net: Not close accept conn when epoll failed #34392
- net/http: shutdown on http.Server serving through net.Listener closes listener twice #24803
- TCPConn.Close() does not close the port leaving it in TIME_WAIT status #32961
- net/rpc: socket fd leak when server closes connection first #6897
(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)
Comment From: seankhliao
1.16 isn't a supported version.
As far as we're aware, Serve does return on a closed listener:
package main
import (
"log"
"net"
"net/http"
"time"
)
func main() {
lis, err := net.Listen("tcp", ":0")
if err != nil {
log.Fatalln(err)
}
svr := &http.Server{}
errc := make(chan error)
go func() {
errc <- svr.Serve(lis)
}()
time.Sleep(time.Second)
log.Println("close lis", lis.Close())
log.Println("serve err", <-errc)
}
results in:
2024/06/25 16:20:15 close lis <nil>
2024/06/25 16:20:15 serve err accept tcp [::]:44157: use of closed network connection
Comment From: lianghao208
1.16 isn't a supported version.
As far as we're aware, Serve does return on a closed listener:
```go package main
import ( "log" "net" "net/http" "time" )
func main() { lis, err := net.Listen("tcp", ":0") if err != nil { log.Fatalln(err) } svr := &http.Server{} errc := make(chan error) go func() { errc <- svr.Serve(lis) }() time.Sleep(time.Second) log.Println("close lis", lis.Close()) log.Println("serve err", <-errc) } ```
results in:
2024/06/25 16:20:15 close lis <nil> 2024/06/25 16:20:15 serve err accept tcp [::]:44157: use of closed network connection
Yes, mostly the 1.16 behaves the same, the server will close after the listener was closed, but sometimes it won't. I can't reproduce it but it keeps happening.
Comment From: lianghao208
@seankhliao I know 1.16 is old, but does this issue remind you of any related issues?
Comment From: ianlancetaylor
There are a bunch of possibly-related issued in the comment by gabyhelp above.