一次docker错误的耗时排查过程记录

由来

客户是深信服的订制系统,基于 centos 改的,排查半天发现居然是文件损坏,而不是 docker 的问题。

环境信息

docker信息:

$ docker info
Containers: 0
 Running: 0
 Paused: 0
 Stopped: 0
Images: 2
Server Version: 18.09.3
Storage Driver: overlay2
 Backing Filesystem: xfs
 Supports d_type: true
 Native Overlay Diff: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: bridge host macvlan null overlay
 Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Init Binary: docker-init
containerd version: e6b3f5632f50dbc4e9cb6288d911bf4f5e95b18e
runc version: 6635b4f0c6af3810594d2770f662f34ddc15b40d
init version: fec3683
Security Options:
 seccomp
 Profile: default
Kernel Version: 3.10.0
Operating System: CentOS Linux 7 (Core)
OSType: linux
Architecture: x86_64
CPUs: 20
Total Memory: 125.3GiB
Name: eds-1f21a854
ID: VZLV:26PU:ZUN6:QQEJ:GW3I:YETT:HMEU:CK6J:SIPL:CHKV:6ASN:5NDF
Docker Root Dir: /data/kube/docker
Debug Mode (client): false
Debug Mode (server): false
Registry: https://index.docker.io/v1/
Labels:
Experimental: false
Insecure Registries:
 reg.wps.lan:5000
 treg.yun.wps.cn
 127.0.0.0/8
Registry Mirrors:
 https://registry.docker-cn.com/
 https://docker.mirrors.ustc.edu.cn/
Live Restore Enabled: false
Product License: Community Engine

系统信息

$ uname -a
Linux eds-1f21a854 3.10.0 #1 SMP Mon Sep 28 12:00:30 CST 2020 x86_64 x86_64 x86_64 GNU/Linux
$ cat /etc/os-release
NAME="CentOS Linux"
VERSION="7 (Core)"
ID="centos"
ID_LIKE="rhel fedora"
VERSION_ID="7"
PRETTY_NAME="CentOS Linux 7 (Core)"
ANSI_COLOR="0;31"
CPE_NAME="cpe:/o:centos:centos:7"
HOME_URL="https://www.centos.org/"
BUG_REPORT_URL="https://bugs.centos.org/"

CENTOS_MANTISBT_PROJECT="CentOS-7"
CENTOS_MANTISBT_PROJECT_VERSION="7"
REDHAT_SUPPORT_PRODUCT="centos"
REDHAT_SUPPORT_PRODUCT_VERSION="7"

服务器信息:

$ cat product_name
SUGON-60G16
$ cat sys_vendor
SANGFOR
$ cat product_version
1.2

排查过程

安装docker服务器挂了

时间2020 10/29 19:51:

实施: 客户这边部署的时候安装docker的时候服务器挂了
我: 开机后/var/log/message有信息吗
实施: 只能恢复快照才能进去,服务器进不了,看不了信息
我: 不恢复快照起不来吗
实施: 是的

到这里我以为是触发了啥内核 bug 直接内核 panic 了服务器起不来。

时间2020 10/30 9:07:

我: 起不来的时候有进控制台去看啥原因起不来吗
实施: 是客户服务器没法查看呢
我: 客户没去看下吗

然后实施直接发来一个向日葵远程连接,我上去后发现不是常规的操作系统,是基于 centos 改过的,没找到/var/log/message,然后手动执行我们的 docker 安装脚本。

bash -x install-docker.sh

然后输出的信息在某一步就没输出了,应该”挂了”,看了下脚本最后一条输出调试信息的后面是启动 docker,应该是启动 docker 触发的。然后很久后还是无法连上和 ping 通,叫实施问问那边现场看看是硬件服务器的话有没有 idrac,ilo 之类的看看 tty 控制台的信息。

现场人员看了下服务器是”正常开机”的,我这边尝试还是连不上,现场问我们的操作是否是改了路由,现场 systemctl 看了下 docker 是起来的。现场那边还是 ping 不通网关。我这边突然想到是不是压根没挂。。。

叫他 uptime -s 看看上次的启动时间,结果压根没重启。。。

然后现场排查到是 iptables 的问题,启动 docker 的时候把他们的规则刷没了。后面他们改了下都放开了。所以前面的启动 docker 把机器挂了实际上是iptables的影响导致网络断开,机器压根没重启。

启动容器挂掉

然后继续,实施说之前同样的其他机器安装 docker 的时候没出现上面的问题,而是启动的时候出现上面的问题,我就手动执行下部署,结果报错。脚本开-x调试看是load 部署镜像的时候报错了。

error during connect: Post http://%2Fvar%2Frun%2Fdocker.sock/v1.39/images/load?quiet=0: read unix @->/var/run/docker.sock: read: EOF

手动执行下:

$ docker load -i ./kube/images/deploy.tar
error during connect: Post http://%2Fvar%2Frun%2Fdocker.sock/v1.39/images/load?quiet=0: read unix @->/var/run/docker.sock: read: connection reset by peer

jounalctl 看了下 docker daemon 没任何相关日志,这个报错搜了下有的人说是 /var/run/docker.sock 的 docker 组不存在,也有人直接chmod 777解决的。试了下还是不行。前台 debug 下 docker 看看有没有有用的信息:

systemctl stop docker
pkill dockerd
dockerd -D

另开一个终端执行 load 镜像操作:

$ docker load -i ./kube/images/deploy.tar
ab6425526dab: Loading layer [==================================================>] 126.3MB/126.3MB
c7fe3ea715ef: Loading layer [==================================================>] 340.3MB/340.3MB
7f7eae7934f7: Loading layer [==================================================>] 3.584kB/3.584kB
e99a66706b50: Loading layer [==================================================>] 2.105MB/2.105MB
245b79de6bb7: Loading layer [==================================================>] 283.5MB/283.5MB
2a56a4432cef: Loading layer [==================================================>] 93.18kB/93.18kB
0c2ea71066ab: Loading layer [==================================================>] 276.5kB/276.5kB
bb3f6df0f87c: Loading layer [==================================================>] 82.94kB/82.94kB
6f34ead3cef7: Loading layer [==================================================>] 946.7kB/946.7kB
c21422dd15f6: Loading layer [==================================================>] 1.97MB/1.97MB
940288517f4c: Loading layer [==================================================>] 458.2kB/458.2kB
0c52f1af61f4: Loading layer [==================================================>] 5.12kB/5.12kB
049e7edd48bc: Loading layer [==================================================>] 1.57MB/1.57MB
73307245d702: Loading layer [==================================================>] 5.632kB/5.632kB
f109309d8ffc: Loading layer [==================================================>] 2.175MB/2.175MB
Loaded image: xxxxxxxxxxxx.cn/platform/deploy-amd64:ubuntu.16.04
$ docker images
REPOSITORY    TAG   IMAGE ID  CREATED  SIZE
xxxxxxxxxxxx.cn/platform/deploy-amd64 ubuntu.16.04 3ad94a76af5d 3 months ago 734MB

调试这边前台日志输出正常

...
DEBU[2020-10-30T14:48:39.955963986+08:00] Applied tar sha256:049e7edd48bc46e3dd5edf89c9caa8f0f7efbb41af403c5a54dd4f1008f604a7 to d58edd0d97bb672ef40e82e45c1603ca3ceaad847d9b9fc7c9b0588087019649, size: 1518278
DEBU[2020-10-30T14:48:39.960091040+08:00] Applying tar in /data/kube/docker/overlay2/b044bd592ae800ed071208c6b2f650c5cbdc7452702f56a23b9b4ffe4236ac18/diff storage-driver=overlay2
DEBU[2020-10-30T14:48:40.059510528+08:00] Applied tar sha256:73307245d7021f9627ca0b2cbfeab3aac0b65abfd476f6ec26bb92c75892d7e2 to b044bd592ae800ed071208c6b2f650c5cbdc7452702f56a23b9b4ffe4236ac18, size: 3284
DEBU[2020-10-30T14:48:40.063040538+08:00] Applying tar in /data/kube/docker/overlay2/03918b1d275aa284532b8b9c59ca158409416f904e13cc7084c598ed343e844f/diff storage-driver=overlay2
DEBU[2020-10-30T14:48:40.148209852+08:00] Applied tar sha256:f109309d8ffcb76589ad6389e80335d986b411c80122d990ab00a02a3a916e3e to 03918b1d275aa284532b8b9c59ca158409416f904e13cc7084c598ed343e844f, size: 2072803
^CINFO[2020-10-30T14:48:55.593523177+08:00] Processing signal 'interrupt'
DEBU[2020-10-30T14:48:55.593617229+08:00] daemon configured with a 15 seconds minimum shutdown timeout
DEBU[2020-10-30T14:48:55.593638628+08:00] start clean shutdown of all containers with a 15 seconds timeout...
DEBU[2020-10-30T14:48:55.594074457+08:00] Unix socket /run/docker/libnetwork/ebd15186e86385c48c4c5508d5f30eb83d5d74e56f09af5c82b6d6d9d63ec8b8.sock doesn't exist. cannot accept client connections
DEBU[2020-10-30T14:48:55.594106623+08:00] Cleaning up old mountid : start.
INFO[2020-10-30T14:48:55.594157536+08:00] stopping event stream following graceful shutdown error="<nil>" module=libcontainerd namespace=moby
DEBU[2020-10-30T14:48:55.594343122+08:00] Cleaning up old mountid : done.
DEBU[2020-10-30T14:48:55.594501828+08:00] Clean shutdown succeeded
INFO[2020-10-30T14:48:55.594520918+08:00] stopping healthcheck following graceful shutdown module=libcontainerd
INFO[2020-10-30T14:48:55.594531978+08:00] stopping event stream following graceful shutdown error="context canceled" module=libcontainerd namespace=plugins.moby
DEBU[2020-10-30T14:48:55.594603119+08:00] received signal    signal=terminated
INFO[2020-10-30T14:48:55.594739890+08:00] pickfirstBalancer: HandleSubConnStateChange: 0xc4201a61b0, TRANSIENT_FAILURE module=grpc
INFO[2020-10-30T14:48:55.594751465+08:00] pickfirstBalancer: HandleSubConnStateChange: 0xc4201a61b0, CONNECTING module=grpc

看了下systemd的配置没啥特殊的,就很迷,不知道为啥前台运行就能导入,后面实在想不到怎么排查,就怀疑可能是 socket 问题,尝试用 socat 转发成 tcp 试试,结果还是不行(此处应该daemon那加tcp 监听127试试,不应该通过socket,socat最终也是过的socket)

$ socat -d -d TCP-LISTEN:2375,fork,bind=127.0.0.1 UNIX:/var/run/docker.sock
2020/10/30 17:39:58 socat[5201] N listening on AF=2 127.0.0.1:2375
^[[C2020/10/30 17:42:06 socat[5201] N accepting connection from AF=2 127.0.0.1:35370 on AF=2 127.0.0.1:2375
2020/10/30 17:42:06 socat[5201] N forked off child process 11501
2020/10/30 17:42:06 socat[5201] N listening on AF=2 127.0.0.1:2375
2020/10/30 17:42:06 socat[11501] N opening connection to AF=1 "/var/run/docker.sock"
2020/10/30 17:42:06 socat[11501] N successfully connected from local address AF=1 "\0\0\0\0\0\0 \x0D\x@7\xE9\xEC\x7E\0\0\0\x01\0\0\0\0"
2020/10/30 17:42:06 socat[11501] N starting data transfer loop with FDs [6,6] and [5,5]
2020/10/30 17:42:12 socat[11501] E write(5, 0x55f098349920, 8192): Broken pipe
2020/10/30 17:42:12 socat[11501] N exit(1)
2020/10/30 17:42:12 socat[5201] N childdied(): handling signal 17

$ docker --log-level debug -H tcp://127.0.0.1:2375 load -i kube/images/deploy.tar
c7fe3ea715ef: Loading layer [==========================================>  ] 286.9MB/340.3MB
unexpected EOF

最后耗了挺久的,当时忙,去看了下另一个客户的问题,然会回到这边,突发奇想的试试 load 其他镜像,结果可以。。。

$ docker load -i kube/images/pause_3.1.tar
e17133b79956: Loading layer [==================================================>] 744.4kB/744.4kB
Loaded image: mirrorgooglecontainers/pause-amd64:3.1
$ docker load -i kube/images/tiller_v2.16.1.tar
77cae8ab23bf: Loading layer [==================================================>] 5.815MB/5.815MB
679105aa33fb: Loading layer [==================================================>] 6.184MB/6.184MB
639eab5d05b1: Loading layer [==================================================>] 40.46MB/40.46MB
87e5687e03f2: Loading layer [==================================================>] 41.13MB/41.13MB
Loaded image: gcr.io/kubernetes-helm/tiller:v2.16.1
$ docker load -i kube/images/calico_v3.1.3.tar
cd7100a72410: Loading layer [==================================================>] 4.403MB/4.403MB
ddc4cb8dae60: Loading layer [==================================================>] 7.84MB/7.84MB
77087b8943a2: Loading layer [==================================================>] 249.3kB/249.3kB
c7227c83afaf: Loading layer [==================================================>] 4.801MB/4.801MB
2e0e333a66b6: Loading layer [==================================================>] 231.8MB/231.8MB
Loaded image: calico/node:v3.1.3
2580685bfb60: Loading layer [==================================================>] 50.84MB/50.84MB
Loaded image: calico/kube-controllers:v3.1.3
0314be9edf00: Loading layer [==================================================>] 1.36MB/1.36MB
15db169413e5: Loading layer [==================================================>] 28.05MB/28.05MB
4252efcc5013: Loading layer [==================================================>] 2.818MB/2.818MB
76cf2496cf36: Loading layer [==================================================>] 3.03MB/3.03MB
91d3d3a16862: Loading layer [==================================================>] 2.995MB/2.995MB
18a58488ba3b: Loading layer [==================================================>] 3.474MB/3.474MB
8d8197f49da2: Loading layer [==================================================>] 27.34MB/27.34MB
7520364e0845: Loading layer [==================================================>] 9.216kB/9.216kB
b9d064622bd6: Loading layer [==================================================>] 2.56kB/2.56kB
Loaded image: calico/cni:v3.1.3

只有导入这个的时候才报错

$ docker load -i kube/images/deploy.tar
error during connect: Post http://%2Fvar%2Frun%2Fdocker.sock/v1.39/images/load?quiet=0: read unix @->/var/run/docker.sock: read: connection reset by peer

然后出包的机器上对比了下这个文件的校验值发现不对。。。。

总结

有个疑问就是为啥前台可以,其次文件损坏导入的时候 docker daemon 居然不刷任何日志直接 connection reset,新版本没测试过这种情况。

到此这篇关于docker错误的耗时排查过程记录的文章就介绍到这了,更多相关docker错误耗时排查内容请搜索我们以前的文章或继续浏览下面的相关文章希望大家以后多多支持我们!

(0)

相关推荐

  • Docker daemon 无法启动: does not match with stored UUID错误解决办法

    Docker daemon 无法启动: does not match with stored UUID错误 最近做项目,遇到Docker daemon 无法启动: does not match with stored UUID错误的问题,经过上网查找资料解决了问题,这里记录下解决办法. Docker 默认使用loop设备存储镜像.使用/var/lib/docker存储.但是当根分区不够大的时候(Centos7默认安装只有50G),那就麻烦了. 这里提供下修改方法(以centos7操作系统为例):

  • Docker容器端口映射后突然无法连接的排查过程

    一.背景 一般需要对外提供服务的Docker容器,我们在启动时后使用-p命令将对外访问端口暴露给外部,例如启动Docker Registry,我们将5000端口映射出来供外部访问: docker run -d -p 5000:5000 registry 但最近碰到一个非常奇怪的情况:研发组里一个CentOS 7测试环境里部署有Docker Registry,并对外暴露了端口.启动容器后一段时间内都是可以正常工作的,但在不定时间间隔后,外部主机就会出现无法从仓库中拉取镜像的情况,提示TimeOut

  • 一次Docker中Redis连接暴增的问题排查实战记录

    周六生产服务器出现redis服务器不可用状态,错误信息为: 状态不可用,等待后台检查程序恢复方可使用.Unexpected end of stream; expected type 'Status' 如下图所示,下图6300就是我们redis服务器运行的端口. 头一次碰到此类问题,心想难道是redis挂掉了,随即通过telnet ip+端口.发现运行正常,然后就想着进入redis看下目前连接情况.一看发现竟然高达1903条这么多. 然后想着应该是代码创建redis连接过多导致的,查看代码. 发现

  • 创建的docker容器时间显示错误/date错误/时区错误

    前几天在测试应用的功能时,发现存入数据库中的数据create_time或者update_time字段总是错误,其他数据都是正常的,只有关于时间的字段是错误的. 进入linux服务器中查看,也没有任何的异常,然后就觉得可能是docker容器的问题,进入到容器中,查看系统时间,果然与宿主机中的时间不同,在网上查了一会儿资料后知道了答案,时区的设置问题,中国的时区为东八区,但是和其他国家的可能会不同,如果在创建容器时没有做修改的话,时区可能就不是东八区了,因此会出现这种类似的问题. 处理方法: ENV

  • Docker出现Cannot connect to the Docker daemon. Is the docker daemon running on this host错误解决办法

    Docker出现Cannot connect to the Docker daemon. Is the docker daemon running on this host错误解决办法 发生现象: ubuntu15下,安装完Docker后,运行docker images 报错Cannot connect to the Docker daemon. Is the docker daemon running on this host? 如下图 图 原因分析: 目前我遇到这个问题是两个原因造成的,一个

  • 一次docker错误的耗时排查过程记录

    由来 客户是深信服的订制系统,基于 centos 改的,排查半天发现居然是文件损坏,而不是 docker 的问题. 环境信息 docker信息: $ docker info Containers: 0 Running: 0 Paused: 0 Stopped: 0 Images: 2 Server Version: 18.09.3 Storage Driver: overlay2 Backing Filesystem: xfs Supports d_type: true Native Overl

  • Docker安装运行SRS的过程记录

    目录 简介 一.window10安装Docker 二.Docker安装centos7 简介 SRS 简介 SRS定位是运营级的互联网直播服务器集群,追求更好的概念完整性和最简单实现的代码.SRS提供了丰富的接入方案将RTMP流接入SRS, 包括推送RTMP到SRS.推送RTSP/UDP/FLV到SRS.拉取流到SRS. SRS还支持将接入的RTMP流进行各种变换,譬如将RTMP流转码.流截图. 转发给其他服务器.转封装成HTTP-FLV流.转封装成HLS. 转封装成HDS.转封装成DASH.录制

  • 基于docker 搭建Prometheus+Grafana的过程详解

    一.介绍Prometheus Prometheus(普罗米修斯)是一套开源的监控&报警&时间序列数据库的组合,起始是由SoundCloud公司开发的.随着发展,越来越多公司和组织接受采用Prometheus,社会也十分活跃,他们便将它独立成开源项目,并且有公司来运作.Google SRE的书内也曾提到跟他们BorgMon监控系统相似的实现是Prometheus.现在最常见的Kubernetes容器管理系统中,通常会搭配Prometheus进行监控. Prometheus基本原理是通过HTT

  • MySQL主从复制问题总结及排查过程

    目录 一.概述 二.mysql主从复制原理 1.MYSQL主从复制过程 三.问题及解决方法 1.show slave status \G 显示如下报错信息 2.根据提示信息定位报错位置 四.通用解决方法 1. 跳过指定数量的事务 2. 跳所有错误或指定类型的错误 一.概述 mysql主从是常用的高可用架构之一,也是使用最广泛的的系统架构.在生产环境中mysql主从复制有时会出现复制错误问题.MySQL主从复制中的问题(Coordinator stopped beacause there were

  • 生产环境MySQL索引时效的排查过程

    早上收到开发同学求助,有个SQL查询耗时特别长,看了执行计划发现没有走索引,但是不知道原因在哪里,我们一起来分析一下. mysql>explain SELECT * FROM artisan_income WHERE parent_id IN ( 222645481, 222583953, 222181775, 222180931, 222081126, 221678753, 221616102, 221591783, 221219312, 221195482, 221118672, 22076

  • Microsoft VBScript 运行时错误 错误 '800a0005' 无效的过程调用或参数: 'chr'

    昨天给公司服务器重做了一下系统,遇到Asp附件无法上传,之前服务器上使用好好的,怎么重做了就不正常了,于是一番google,baidu,下面将解决办法送出,帮助碰到该问题的朋友少走弯路: 1,权限问题 请确保您所上传文件的文件夹"来宾用户"有可写入的权限,有的是存入数据库的,也要有修改权限.  2,文件大小限制 IIS 6 出于安全考虑, 默认最大请求200K(也即最大提交数据限额为200KByte, 204800Byte). 解决办法:       关闭 IIS Admin Serv

  • MySQL5.6升级5.7时出现主从延迟问题排查过程

    最近在做zabbix的数据库MySQL5.6升级5.7时,出现主从延迟问题,这个问题困扰了很久没有解决,昨天终于解决了,整理了一下整个排查过程,分享给大家. 环境说明: mysql主库为5.6的版本,有四个从库,三个为5.6的版本,一个为5.7的版本,所有主从的库表结构均一致,5.7的从库出现大量延迟,5.6的没问题,业务为zabbix监控,基本全部为insert批量插入操作,每条insert SQL插入数据为400-1000行左右. 问题: MySQL5.7的从库大量延迟,relaylog落盘

  • nodejs的错误处理过程记录

    本文以连接错误ECONNREFUSED为例,看看nodejs对错误处理的过程. 假设我们有以下代码 1. const net = require('net'); 2. net.connect({port: 9999}) 如果本机上没有监听9999端口,那么我们会得到以下输出. 1. events.js:170 2. throw er; // Unhandled 'error' event 3. ^ 4. 5. Error: connect ECONNREFUSED 127.0.0.1:9999

  • Docker启动mysql配置实现过程

    目录 实战过程 前言 可以通过官网查询其mysql如何启动 以及对mysql中的一些解读 附上官网地址 启动另一个mysql容器实例并运行mysql命令mysql是世界上最流行的开源数据库. 由于其经过验证的性能,可靠性和易用性,MySQL已经成为基于web的应用程序的领先数据库选择,涵盖了从个人项目和网站,通过电子商务和信息服务,一路到高知名度的web属性,包括Facebook, Twitter, YouTube, Yahoo! 和许多更多. 实战过程 通过查询官网具体白皮书 可得知使用这条命

随机推荐