切换语言

Docker 守护进程故障排除

故障排除
目录

本页面介绍了在遇到问题时如何对守护进程进行故障排除和调试。

您可以在守护进程上开启调试功能，以了解守护进程的运行活动并帮助进行故障排除。如果守护进程无响应，您还可以 强制生成所有线程的完整堆栈跟踪 ，方法是将 SIGUSR 信号发送到 Docker 守护进程，以将堆栈跟踪添加到守护进程日志中。

守护进程

无法连接到 Docker 守护进程

Cannot connect to the Docker daemon. Is 'docker daemon' running on this host?

此错误可能表示：

  • Docker 守护进程未在您的系统上运行。启动守护进程并尝试 再次运行该命令。
  • 您的 Docker 客户端正尝试连接到不同主机上的 Docker 守护进程，但该主机无法访问。

检查Docker是否正在运行

检查 Docker 是否正在运行的不依赖于操作系统的方法是 使用 docker info 命令询问 Docker。

您也可以使用操作系统实用工具，例如 sudo systemctl is-active docker 或 sudo status docker 或 sudo service docker status，或使用 Windows 实用工具检查服务状态。

最后，您可以在进程列表中检查 dockerd 进程，使用 类似 ps 或 top 的命令。

检查您的客户端正在连接到哪个主机

要查看您的客户端正在连接到哪个主机，请检查您的环境中的 DOCKER_HOST 变量的值。

$ env | grep DOCKER_HOST

如果此命令返回一个值，则 Docker 客户端被设置为连接到在该主机上运行的 Docker 守护进程。如果未设置，则 Docker 客户端被设置为连接到在本地主机上运行的 Docker 守护进程。如果设置错误，请使用以下命令取消设置：

$ unset DOCKER_HOST

您可能需要在诸如 ~/.bashrc 或 ~/.profile 的文件中编辑您的环境，以防止 DOCKER_HOST 变量被错误地设置。

如果按预期设置了 DOCKER_HOST，请验证 Docker 守护进程是否在远程主机上运行，以及防火墙或网络中断是否阻止了您连接。

排查 daemon.json 和启动脚本之间的冲突

如果您使用 daemon.json 文件，并且手动或使用启动脚本向 dockerd 命令传递选项，而这些选项发生冲突，Docker 将无法启动并显示如下错误：

unable to configure the Docker daemon with file /etc/docker/daemon.json:
the following directives are specified both as a flag and in the configuration
file: hosts: (from flag: [unix:///var/run/docker.sock], from file: [tcp://127.0.0.1:2376])

如果您看到类似于此的错误并且您正在使用标志手动启动守护进程， 您可能需要调整您的标志或 daemon.json 以消除 冲突。

注意

如果您看到关于 hosts 的特定错误消息，请继续阅读 下一节 以获取解决方法。

如果您使用操作系统的初始化脚本来启动 Docker，可能需要以特定于操作系统的方式覆盖这些脚本中的默认值。

使用 systemd 配置守护进程主机

一个难以排查的配置冲突的显著示例是，当您想要指定一个与默认值不同的守护进程地址时。Docker 默认监听一个套接字。在使用 systemd 的 Debian 和 Ubuntu 系统上，这意味着在启动 dockerd 时总是使用主机标志 -H。如果您在 daemon.json 中指定了一个 hosts 条目，这会导致配置冲突，并导致 Docker 守护进程启动失败。

要解决此问题，请创建一个新文件 /etc/systemd/system/docker.service.d/docker.conf，内容如下， 以移除默认启动守护进程时使用的-H参数。

[Service]
ExecStart=
ExecStart=/usr/bin/dockerd

在其他时候，您可能需要使用 Docker 配置 systemd，例如 配置 HTTP 或 HTTPS 代理。

注意

如果在手动启动 Docker 时未在 hosts 中指定 daemon.json 条目或 -H 标志的情况下覆盖此选项，Docker 将无法启动。

在尝试启动 Docker 之前，先运行 sudo systemctl daemon-reload。如果 Docker 成功启动，它现在将监听 daemon.json 中 hosts 键指定的 IP 地址，而不是套接字。

重要

在 Docker Desktop for Windows 或 Docker Desktop for Mac 上不支持将 daemon.json 中的 hosts 设置为 0。

内存不足问题

如果您的容器尝试使用超过系统可用内存的内存，您可能会遇到内存不足（OOM）异常，并且容器或Docker守护进程可能会被内核OOM终止程序停止。为防止这种情况发生，请确保您的应用程序在具有足够内存的主机上运行，并参阅 了解内存不足的风险。

内核兼容性

如果您的内核版本低于 3.10，或者缺少内核模块，Docker 将无法正常运行。要检查内核兼容性，您可以下载并运行 check-config.sh 脚本。

$ curl https://raw.githubusercontent.com/docker/docker/master/contrib/check-config.sh > check-config.sh

$ bash ./check-config.sh

该脚本仅在 Linux 上运行。

内核 cgroup 交换限制功能

在 Ubuntu 或 Debian 主机上，在使用镜像时，您可能会看到类似于以下的信息。

WARNING: Your kernel does not support swap limit capabilities. Limitation discarded.

如果不需要这些功能，您可以忽略该警告。

您可以通过按照这些说明在 Ubuntu 或 Debian 上启用这些功能。内存和交换记账会占用大约 1% 的总可用内存，并导致 10% 的整体性能下降，即使 Docker 没有运行时也是如此。

  1. 以具有 sudo 权限的用户身份登录 Ubuntu 或 Debian 主机。

  2. 编辑 /etc/default/grub 文件。添加或编辑 GRUB_CMDLINE_LINUX 行 以添加以下两个键值对：

    GRUB_CMDLINE_LINUX="cgroup_enable=memory swapaccount=1"

    保存并关闭文件。

  3. 更新 GRUB 引导加载程序。

    $ sudo update-grub

    如果您的 GRUB 配置文件语法不正确，则会出现错误。在这种情况下，请重复步骤 2 和 3。

    更改在您重启系统时生效。

网络

IP转发问题

如果您使用 systemd 版本 219 或更高版本通过 systemd-network 手动配置网络，Docker 容器可能无法访问您的网络。 从 systemd 版本 220 开始，给定网络的转发设置（net.ipv4.conf.<interface>.forwarding）默认为关闭。此设置会阻止 IP 转发。它还与 Docker 在容器内启用 net.ipv4.conf.all.forwarding 设置的行为冲突。

要在 RHEL、CentOS 或 Fedora 上解决此问题，请编辑 Docker 主机上 /usr/lib/systemd/network/ 中的 <interface>.network 文件，例如， /usr/lib/systemd/network/80-container-host0.network。

在 [Network] 部分中添加以下代码块。

[Network]
...
IPForward=kernel
# OR
IPForward=true

此配置允许按预期从容器转发 IP。

DNS 解析器问题

DNS resolver found in resolv.conf and containers can't use it

Linux 桌面环境通常运行一个网络管理程序，该程序使用 dnsmasq 通过将 DNS 请求添加到 /etc/resolv.conf 来缓存它们。dnsmasq 实例运行在环回地址上，例如 127.0.0.1 或 127.0.1.1。它加速 DNS 查询并提供 DHCP 服务。这种配置在 Docker 容器中不起作用。Docker 容器使用自己的网络命名空间，并将环回地址（如 127.0.0.1）解析为自身，并且不太可能在其自己的环回地址上运行 DNS 服务器。

如果 Docker 检测到 /etc/resolv.conf 中引用的 DNS 服务器不是完全功能的 DNS 服务器，则会出现以下警告：

WARNING: Local (127.0.0.1) DNS resolver found in resolv.conf and containers
can't use it. Using default external servers : [8.8.8.8 8.8.4.4]

如果您看到此警告，请首先检查是否使用了 dnsmasq：

$ ps aux | grep dnsmasq

如果您的容器需要解析您网络内部的主机，公共名称服务器是不够的。您有两个选择：

  • 指定 Docker 使用的 DNS 服务器。

  • 关闭 dnsmasq。

    关闭 dnsmasq 会将实际 DNS 名称服务器的 IP 地址添加到 /etc/resolv.conf，并且您将失去 dnsmasq 的优势。

您只需使用其中一种方法。

指定 Docker 的 DNS 服务器

配置文件的默认位置是 /etc/docker/daemon.json。您可以使用 --config-file 守护进程标志来更改配置文件的位置。以下说明假设配置文件的位置是 /etc/docker/daemon.json。

  1. 创建或编辑 Docker 守护进程配置文件，默认为 /etc/docker/daemon.json 文件，该文件控制 Docker 守护进程 配置。

    $ sudo nano /etc/docker/daemon.json

  2. 添加一个 dns 键，其值为一个或多个 DNS 服务器 IP 地址。

    {
  "dns": ["8.8.8.8", "8.8.4.4"]
}

    如果文件已有内容，您只需添加或编辑第 dns 行。如果您的内部DNS服务器无法解析公共IP地址，请至少包含一个能够解析的DNS服务器。这样做可以让您连接到Docker Hub，并使您的容器能够解析互联网域名。

    保存并关闭文件。

  3. 重启 Docker 守护进程。

    $ sudo service docker restart

  4. 通过尝试拉取镜像来验证 Docker 是否可以解析外部 IP 地址：

    $ docker pull hello-world

  5. 如有必要，请通过 ping 验证 Docker 容器是否能够解析内部主机名。

    $ docker run --rm -it alpine ping -c4 <my_internal_host>

PING google.com (192.168.1.2): 56 data bytes
64 bytes from 192.168.1.2: seq=0 ttl=41 time=7.597 ms
64 bytes from 192.168.1.2: seq=1 ttl=41 time=7.635 ms
64 bytes from 192.168.1.2: seq=2 ttl=41 time=7.660 ms
64 bytes from 192.168.1.2: seq=3 ttl=41 time=7.677 ms

关闭 dnsmasq

如果您不想更改 Docker 守护进程的配置以使用特定的 IP 地址，请按照以下说明在 NetworkManager 中关闭 dnsmasq。

  1. 编辑 /etc/NetworkManager/NetworkManager.conf 文件。

  2. 通过在行首添加一个 # 字符来注释掉 dns=dnsmasq 行。

    # dns=dnsmasq

    保存并关闭文件。

  3. 重启 NetworkManager 和 Docker。或者，你可以重新启动 你的系统。

    $ sudo systemctl restart network-manager
$ sudo systemctl restart docker

要在 RHEL、CentOS 或 Fedora 上关闭 dnsmasq：

  1. 关闭 dnsmasq 服务：

    $ sudo systemctl stop dnsmasq
$ sudo systemctl disable dnsmasq

  2. 使用 Red Hat 文档 手动配置 DNS 服务器。

Docker 网络消失

如果 Docker 网络（例如 docker0 桥接或自定义网络）随机消失或似乎工作不正常，可能是因为 另一个服务正在干扰或修改 Docker 接口。已知管理主机网络接口的工具有时也会 不当修改 Docker 接口。

请参考以下章节，了解如何根据主机上存在的网络管理工具，配置网络管理器将 Docker 接口设置为非托管：

卸载 netscript

如果您的系统上安装了 netscript，您可以通过卸载它来解决此问题。例如，在基于 Debian 的系统上：

$ sudo apt-get remove netscript-2.4

非托管 Docker 接口

在某些情况下，网络管理器默认会尝试管理 Docker 接口。您可以通过编辑系统的网络配置设置，将 Docker 网络显式标记为非托管状态。

如果您正在使用 NetworkManager，请在 /etc/network/interfaces 下编辑您的系统网络配置

  1. 在 /etc/network/interfaces.d/20-docker0 处创建一个文件，内容如下：

    iface docker0 inet manual

    请注意，此示例配置仅“取消管理”默认的 docker0 网桥，而非自定义网络。

  2. 重启 NetworkManager 以使配置更改生效。

    $ systemctl restart NetworkManager

  3. 验证 docker0 接口是否处于 unmanaged 状态。

    $ nmcli device

如果您在使用 systemd-networkd 作为网络守护进程的系统上运行 Docker，请通过在 /etc/systemd/network 下创建配置文件将 Docker 接口配置为不受管理：

  1. 创建包含以下内容的 /etc/systemd/network/docker.network：

    # Ensure that the Docker interfaces are un-managed

[Match]
Name=docker0 br-* veth*

[Link]
Unmanaged=yes

  2. 重新加载配置。

    $ sudo systemctl restart systemd-networkd

  3. 重启 Docker 守护进程。

    $ sudo systemctl restart docker

  4. 验证 Docker 接口的状态是否为 unmanaged。

    $ networkctl

防止 Netplan 覆盖网络配置

在使用通过 Netplan 的 cloud-init 的系统上，您可能 需要应用自定义配置以防止 netplan 覆盖 网络管理器配置：

  1. 按照 取消管理 Docker 接口 中的步骤创建网络管理器配置。

  2. 在 /etc/netplan/50-cloud-init.yml 下创建一个 netplan 配置文件。

    以下示例配置文件是一个起点。 请根据您想要取消管理的接口进行调整。 错误的配置可能会导致网络连接问题。

    /etc/netplan/50-cloud-init.yml
    network:
  ethernets:
    all:
      dhcp4: true
      dhcp6: true
      match:
        # edit this filter to match whatever makes sense for your system
        name: en*
  renderer: networkd
  version: 2

  3. 应用新的 Netplan 配置。

    $ sudo netplan apply

  4. 重启 Docker 守护进程：

    $ sudo systemctl restart docker

  5. 验证 Docker 接口的状态是否为 unmanaged。

    $ networkctl

卷

无法移除文件系统

Error: Unable to remove filesystem

一些基于容器的实用工具，例如 Google cAdvisor，将 Docker 系统 目录，例如 /var/lib/docker/，挂载到容器中。例如， cadvisor 的文档指示您按如下方式运行 cadvisor 容器：

$ sudo docker run \
  --volume=/:/rootfs:ro \
  --volume=/var/run:/var/run:rw \
  --volume=/sys:/sys:ro \
  --volume=/var/lib/docker/:/var/lib/docker:ro \
  --publish=8080:8080 \
  --detach=true \
  --name=cadvisor \
  google/cadvisor:latest

当您绑定挂载 /var/lib/docker/ 时，这实际上将所有其他运行中容器的所有资源作为文件系统挂载到挂载 /var/lib/docker/ 的容器内。当您尝试删除其中任何一个容器时，删除尝试可能会失败，并显示类似以下的错误：

Error: Unable to remove filesystem for
74bef250361c7817bee19349c93139621b272bc8f654ae112dd4eb9652af9515:
remove /var/lib/docker/containers/74bef250361c7817bee19349c93139621b272bc8f654ae112dd4eb9652af9515/shm:
Device or resource busy

如果绑定挂载 /var/lib/docker/ 的容器在 /var/lib/docker/ 内的文件系统句柄上使用 statfs 或 fstatfs 并且没有关闭它们，就会出现问题。

通常，我们不建议以这种方式绑定挂载 /var/lib/docker。 然而，cAdvisor 的核心功能需要此绑定挂载。

如果您不确定哪个进程导致错误中提到的路径被占用并阻止其被删除，您可以使用 lsof 命令查找其进程。例如，对于上述错误：

$ sudo lsof /var/lib/docker/containers/74bef250361c7817bee19349c93139621b272bc8f654ae112dd4eb9652af9515/shm

要解决此问题，请停止挂载了 /var/lib/docker 的容器，然后再次尝试删除另一个容器。