dockerd 造成 too many open files

一台运行时长约5天的机器，被发现 docker 无法使用,且其他操作报错 too many open files。

docker version: 19.03

排查

docker client 报错 Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?
lsof 查看，没有输出... 为文件描述符过多。数分钟后有输出其中包含大量 “/var/run/docker.dock” 推测为 docker 客户端使用不当造成。一般为连接使用后未关闭。
lsof /var/run/docker.sock 查看该文件FD持有者发现为 dockerd ,遂进入dockerd查找问题。
查看 dockerd 日志，日志显示是由于连接不上 docker-libnetwork plugin，发现该插件服务处于停止状态，理论上将其启动即可，但治标不治本，到底为什么这种情况会导致如此多的FD占用。

# journalctl -xe -u docker.service -f
5月 06 10:57:23 node-2-76 dockerd[5082]: time="2020-05-06T10:57:23.395950238+08:00" level=error msg="1484f4ee9031a4e560c55ed4fdbc68689a668209f4b18b92350e3830969026ec cleanup: failed to delete container from containerd: no such container"
5月 06 10:57:24 node-2-76 dockerd[5082]: time="2020-05-06T10:57:24.387829239+08:00" level=warning msg="Unable to locate plugin: calico-ipam, retrying in 2s"
5月 06 10:57:26 node-2-76 dockerd[5082]: time="2020-05-06T10:57:26.388193568+08:00" level=warning msg="Unable to locate plugin: calico-ipam, retrying in 4s"
5月 06 10:57:30 node-2-76 dockerd[5082]: time="2020-05-06T10:57:30.388593845+08:00" level=warning msg="Unable to locate plugin: calico-ipam, retrying in 8s"

继续查看 dockerd trace，docker 开启了 pprof 端点。

 curl --unix-socket /var/run/docker.sock "http://./debug/pprof/goroutine?debug=2" > docker.trace

发现其中有许多goroutine处于 semacquire 状态，该状态是在等待锁，且有时长最大高达 8355 分钟的。

goroutine 2195141 [semacquire, 5306 minutes]:
sync.runtime_SemacquireMutex(0xc0004aa704, 0xc00c3cd700)
    /usr/local/go/src/runtime/sema.go:71 +0x3f
sync.(*Mutex).Lock(0xc0004aa700)
    /usr/local/go/src/sync/mutex.go:134 +0x10b
github.com/docker/docker/daemon.(*Daemon).ContainerStart.func1(0x0, 0x0)
    /root/rpmbuild/BUILD/src/engine/.gopath/src/github.com/docker/docker/daemon/start.go:29 +0x45

查看源码 github.com/docker/docker/daemon/start.go:29 确实在等锁，如果是在等锁。则是由于有地方长期未释放锁。注意查找使用 container.Lock() 的地方。
```
// https://github.com/moby/moby/blob/19.03/daemon/start.go#L29
28  validateState := func() error {
29      container.Lock()
30      defer container.Unlock()
```

鉴于上述发现的 network plugin 不可用基础上，一番寻找后发现：

//https://github.com/moby/moby/blob/master/daemon/container_operations.go#L1065
1061 func (daemon *Daemon) ConnectToNetwork(container *container.Container, idOrName string, endpointConfig *networktypes.EndpointSettings) error {
1062    if endpointConfig == nil {
1063        endpointConfig = &networktypes.EndpointSettings{}
1064    }
1065    container.Lock()
1066    defer container.Unlock()

该部分执行了所有关于 docker网络相关的操作，最终追踪到这里，该处会不同的尝试调用相关插件，直到插件可用，才会继续执行。

// https://github.com/moby/moby/blob/master/pkg/plugins/plugins.go#L208
func loadWithRetry(name string, retry bool) (*Plugin, error) {
...
208 for {
        pl, err := registry.Plugin(name)
        if err != nil {
            if !retry {
                return nil, err
            }

            timeOff := backoff(retries)
            if abort(start, timeOff) {
                return nil, err
            }
            retries++
220         logrus.Warnf("Unable to locate plugin: %s, retrying in %v", name, timeOff)
            time.Sleep(timeOff)
            continue
        }
...
241     return pl, err
    }
}

似乎已经知道了，在 network-plugin 不可用的状态下，所有依赖plugin的操作均会阻塞。我们继续使用 docker start [container] 验证它，果然，使用了 network plugin 的容器无法启动，也无法被删除。
查看 FD lsof /var/run/docker.sock | wc -l 会发现，每次 docker start 并 ctrl-c 后，FD 计数会 +1 。因 start 操作发送给 dockerd 后dockerd会阻塞该请求直到插件可用。
在程序中，docker start 基于 context timeout，如果超时，则取消start 请求，等待数秒后在此start，如此，在很长一段时间后FD逐渐超标。直至达到限制。

解决方案

改变 calico-libnetwork-plugin 重启方式
改变调用 docker client 方式，不实用超时context，一个请求阻塞直到 dockerd 返回。

docker client 使用不当造成 too many open files

docker client 使用不当造成 too many open files

dockerd 造成 too many open files

排查

解决方案