八個Docker常見故障
https://mp.weixin.qq.com/s/2GNKmRJtBGHhUyVBRbRgeA
報錯一：error initializing graphdriver
Docker啟動報錯
系統(tǒng)是CentOS 7.2
系統(tǒng)內(nèi)核及docker版本如下 ：
[root@docker ~]# uname -r
3.10.0-327.el7.x86_64
[root@docker ~]#
[root@docker ~]#
[root@docker ~]#
[root@docker ~]# docker version
Client:
Version: 18.04.0-ce
API version: 1.37
Go version: go1.9.4
Git commit: 3d479c0
Built: Tue Apr 10 18:21:36 2018
OS/Arch: linux/amd64
Experimental: false
Orchestrator: swarm
Server:
Engine:
Version: 18.04.0-ce
API version: 1.37 (minimum version 1.12)
Go version: go1.9.4
Git commit: 3d479c0
Built: Tue Apr 10 18:25:25 2018
OS/Arch: linux/amd64
Experimental: false
啟動報錯提示如下 ：
[root@docker ~]# systemctl start docker
Job for docker.service failed because the control process exited with error code. See "systemctl status docker.service" and "journ
[root@docker ~]#
[root@docker ~]#
[root@docker ~]#
[root@docker ~]# systemctl status docker
● docker.service - Docker Application Container Engine
Loaded: loaded (/usr/lib/systemd/system/docker.service; disabled; vendor preset: disabled)
Active: failed (Result: start-limit) since 日 2018-04-22 20:52:39 CST; 5s ago
Docs: https://docs.docker.com
Process: 4810 ExecStart=/usr/bin/dockerd (code=exited, status=1/FAILURE)
Main PID: 4810 (code=exited, status=1/FAILURE)
4月 22 20:52:39 docker.cgy.com systemd[1]: Failed to start Docker Application Container Engine.
4月 22 20:52:39 docker.cgy.com systemd[1]: Unit docker.service entered failed state.
4月 22 20:52:39 docker.cgy.com systemd[1]: docker.service failed.
4月 22 20:52:39 docker.cgy.com systemd[1]: docker.service holdoff time over, scheduling restart.
4月 22 20:52:39 docker.cgy.com systemd[1]: start request repeated too quickly for docker.service
4月 22 20:52:39 docker.cgy.com systemd[1]: Failed to start Docker Application Container Engine.
4月 22 20:52:39 docker.cgy.com systemd[1]: Unit docker.service entered failed state.
4月 22 20:52:39 docker.cgy.com systemd[1]: docker.service failed.
從以上報錯提示信息中也沒看到錯誤的具體原因。然后我又用dockerd來直接啟動惠勒，就在輸出信息最下面看到一條錯誤提示赚抡，如下：
[root@docker ~]# dockerd
INFO[2018-04-22T21:12:46.111704443+08:00] libcontainerd: started new docker-containerd process pid=5903
INFO[0000] starting containerd module=containerd revision=773c489c9c1b21a6d78b5c538cd395416ec50f88 version=v1.0.3
。纠屋。涂臣。。售担。赁遗。省略一部分輸出。族铆。岩四。。哥攘。剖煌。
INFO[0000] loading plugin "io.containerd.grpc.v1.introspection"... module=containerd type=io.containerd.grpc.v1
INFO[0000] serving... address="/var/run/docker/containerd/docker-containerd-debug.sock" module="containerd/debug"
INFO[0000] serving... address="/var/run/docker/containerd/docker-containerd.sock" module="containerd/grpc"
INFO[0000] containerd successfully booted in 0.002763s module=containerd
Error starting daemon: error initializing graphdriver: overlay: the backing xfs filesystem is formatted without d_type support, which leads to incorrect behavior. Reformat the filesystem with ftype=1 to en d_type support. Backing filesystems without d_type support are not supported.
根據(jù)最后的報錯Error starting daemon:搜索到這篇博客，得到解決逝淹。
https://blog.csdn.net/liu9718214/article/details/79134900
具體解決辦法是：
vim /etc/sysconfig/docker
加入如下：
OPTIONS="--selinux-enabled --log-driver=journald --signature-verification=false"
/etc/docker/daemon.json
加入如下內(nèi)容：
{
"registry-mirrors": ["http://4a1df5ef.m.daocloud.io"], # 是用來pull容器加速用的耕姊，跟此次問題無關(guān)。
"storage-driver": "devicemapper" # 解決此次問題
}
然后重啟docker栅葡，順利解決：
[root@docker ~]# systemctl restart docker
[root@docker ~]#
[root@docker ~]#
[root@docker ~]# ps aux | grep docker
root 5922 1.7 1.6 528432 62568 ? Ssl 21:15 0:00 /usr/bin/dockerd
root 5927 1.1 0.5 356984 22100 ? Ssl 21:15 0:00 docker-containerd --config /var/run/docker/containerd/containerd.toml
root 6028 0.0 0.0 112664 964 pts/0 S+ 21:15 0:00 grep --color=auto docker
報錯二：iptables failed
FirewallD
CentOS-7 中介紹了 firewalld茉兰，firewall的底層是使用iptables進行數(shù)據(jù)過濾，建立在iptables之上妥畏，這可能會與 Docker 產(chǎn)生沖突邦邦。
當(dāng) firewalld 啟動或者重啟的時候，將會從 iptables 中移除 DOCKER 的規(guī)則醉蚁，從而影響了 Docker 的正常工作燃辖。
當(dāng)你使用的是 Systemd 的時候， firewalld 會在 Docker 之前啟動网棍，但是如果你在 Docker 啟動之后再啟動 或者重啟 firewalld 黔龟，你就需要重啟 Docker 進程了。
系統(tǒng)：
[root@controller ~]# cat /etc/redhat-release
CentOS Linux release 7.0.1406 (Core)
報錯提示如下：
[root@controller ~]# docker run -it -P docker.io/nginx
/usr/bin/docker-current: Error response from daemon: driver failed programming external connectivity on endpoint gloomy_kirch (10289e7a87e65771da90cda531951b7339bee9cb5953474460451cd48013aff0): iptables failed: iptables --wait -t nat -A DOCKER -p tcp -d 0/0 --dport 32810 -j DNAT --to-destination 172.17.0.2:80 ! -i docker0: iptables: No chain/target/match by that name.
(exit status 1).
這是由于在運行這次容器之前，成功啟動過一次氏身，在上次訪問時巍棱，因為防火墻的問題導(dǎo)致不能正常訪問Nginx，所以將iptables的filter表清空了蛋欣，并且重啟過iptables航徙，然后再次運行時，就報了以上錯誤陷虎。
解決辦法
重啟防火墻
#CentOS 7下執(zhí)行
[root@controller ~]# systemctl restart firewalld
再重啟docker守護進程即可
[root@controller ~]# systemctl restart docker
再次在容器中運行一個nginx就不會報錯了
[root@controller ~]# docker run -it --name nginx -p 80:80 -v /www:/wwwroot docker.io/nginx /bin/bash
root@a8a92c8f7760:/#
報錯三 : Unable to take ownership of thin-pool
docker daemon啟動失數教ぁ：Unable to take ownership of thin-pool
Apr 27 13:51:59 master systemd: Started Docker Storage Setup.
Apr 27 13:51:59 master systemd: Starting Docker Application Container Engine...
Apr 27 13:51:59 master dockerd-current: time="2018-04-27T13:51:59.088441356+08:00" level=warning msg="could not change group /var/run/docker.sock to docker: group docker not found"
Apr 27 13:51:59 master dockerd-current: time="2018-04-27T13:51:59.091166189+08:00" level=info msg="libcontainerd: new containerd process, pid: 20930"
Apr 27 13:52:00 master dockerd-current: Error starting daemon: error initializing graphdriver: devmapper: Unable to take ownership of thin-pool (docker--vg-docker--pool) that already has used data blocks
Apr 27 13:52:00 master systemd: docker.service: main process exited, code=exited, status=1/FAILURE
Apr 27 13:52:00 master systemd: Failed to start Docker Application Container Engine.
Apr 27 13:52:00 master systemd: Unit docker.service entered failed state.
Apr 27 13:52:00 master systemd: docker.service failed
原因： /var/lib/docker/devicemapper/metadata/ 內(nèi)metadata丟失
workaround：
https://bugzilla.redhat.com/show_bug.cgi?id=1321640#c5
Eric Paris 2016-04-27 08:20:10 EDT
I feel like the kcs kinda misses telling users the actual problem. Nor does it really make it clear the solution.
IF you are using device mapper (instead of loopback) /var/lib/docker contains metadata informing docker about the contents of the device mapper storage area. If you delete /var/lib/docker that metadata is lost. Docker is then able to detect that the thin pool has data but docker is unable to make use of that information. The only solution is to delete the thin pool and recreate it so that both the thin pool and the metadata in /var/lib/docker will be empty.
解決辦法：
- 執(zhí)行命令：
rm -rf /var/lib/docker/* - 執(zhí)行命令：
rm -rf /etc/sysconfig/docker-storage - 執(zhí)行命令：
lvremove /dev/docker-vg/docker-pool - 使用現(xiàn)有的docker-vg LVM卷組：
cat <<EOF > /etc/sysconfig/docker-storage-setup
VG=docker-vg
EOF
- 執(zhí)行命令：
docker-storage-setup - 重啟docker即可：
systemctl start docker
報錯四： write /sys/fs/cgroup/cpuset/docker/cpuset.cpus: invalid argument
docker run運行容器時報出如下錯誤：
[root@backup-system cpu]# docker run -ti --name hkp_ubuntu --cpuset-cpus=0-3 ubuntu bash
docker: Error response from daemon: OCI runtime create failed: container_linux.go:370: starting container process caused: process_linux.go:326: applying cgroup configuration for process caused: failed to write "0-3\n" to "/sys/fs/cgroup/cpuset/docker/cpuset.cpus": write /sys/fs/cgroup/cpuset/docker/cpuset.cpus: invalid argument: unknown.
這個錯誤是因為該cgroup的cpu正在被其它cgroup使用，所以不能設(shè)置獨占尚猿。
因此需要先檢查并調(diào)整各個cgroup的cpuset.cpus窝稿，確保當(dāng)前cgroup所用的cpu的確只分配給它了，那么此時就可以設(shè)置cpu_exclusive獨占了凿掂。
當(dāng)前的具體原因是做實驗在 /sys/fs/cgroup/cpuset/新建了 container目錄伴榔，并把 container/cpuset.cpus 設(shè)置為了 0-3
[root@backup-system docker]# cat /sys/fs/cgroup/cpuset/container/cpuset.cpus
0-3
解決方法：
將/sys/fs/cgroup/cpuset/container/cpuset.cpus設(shè)為空后，上述問題得到解決庄萎。
具體原因可查看此篇博客：https://www.lenky.info/archives/2019/03/2679
