docker restart 会影响宿主机网络协议栈吗？

[c4923]

问题：因业务需求，我在 Linux 上做了一个定时任务，定时执行重启容器的脚本。脚本内容如下:

#!/bin/bash
# enable_permission.sh - 启用权限要求配置

# ===== 配置区域 =====
CONFIG_DIR=""    # 配置文件目录
CONFIG_TRUE=""    # 启用权限的配置文件
TARGET_CONFIG=""       # 目标配置文件名
CONTAINER_NAME=""            # Docker 容器名称
LOG_FILE="/var/log/permission_config.log" # 共享日志文件

# ===== 日志函数 =====
log() {
    local timestamp=$(date '+%Y-%m-%d %H:%M:%S')
    local script_name=$(basename "$0")
    echo "[$timestamp] [$script_name] $1" >> "$LOG_FILE"
}

# ===== 主函数 =====
main() {
    log "开始执行"
    
    # 1. 验证配置文件存在
    if [[ ! -f "$CONFIG_DIR/$CONFIG_TRUE" ]]; then
        log "错误: 配置文件 $CONFIG_TRUE 不存在!"
        exit 1
    fi
    
    
    # 3. 复制配置文件
    cp -f "$CONFIG_DIR/$CONFIG_TRUE" "$CONFIG_DIR/$TARGET_CONFIG"
    log "复制配置: $CONFIG_TRUE → $TARGET_CONFIG"
    
    # 4. 重启容器
    if docker restart "$CONTAINER_NAME" > /dev/null; then
        log "容器重启成功"
    else
        log "容器重启失败"
        exit 2
    fi
}

main

总体来言就是每天白天八点重启一次服务容器，晚上八点重启一次服务容器。 这个定时任务已经执行了一周多了，一直没有问题，但是昨晚十点客户那边发现服务无法访问，我上去看了下连二进制部署的宝塔也无法访问了。猜测是服务器网络崩了。然后今天上午八点 40 左右上班连接时发现服务恢复正常了。 查了下/var/log/message,个人感觉比较重要的部分如下：

Aug 14 20:00:11 cap dockerd: time="2025-08-14T20:00:11.500905584+08:00" level=info msg="Container failed to exit within 10s of signal 15 - using the force" container=90828a5018f0fc3eb7019d2f5275b35eb9e79f5306e8aab459e12aaa287ed02a spanID=22a255e634fb0b5f traceID=5222a14c8585e9c7f65d909613b195d0
Aug 14 20:00:11 cap containerd: time="2025-08-14T20:00:11.604295589+08:00" level=info msg="shim disconnected" id=90828a5018f0fc3eb7019d2f5275b35eb9e79f5306e8aab459e12aaa287ed02a
Aug 14 20:00:11 cap containerd: time="2025-08-14T20:00:11.604343484+08:00" level=warning msg="cleaning up after shim disconnected" id=90828a5018f0fc3eb7019d2f5275b35eb9e79f5306e8aab459e12aaa287ed02a namespace=moby
Aug 14 20:00:11 cap containerd: time="2025-08-14T20:00:11.604354005+08:00" level=info msg="cleaning up dead shim"
Aug 14 20:00:11 cap dockerd: time="2025-08-14T20:00:11.604547353+08:00" level=info msg="ignoring event" container=90828a5018f0fc3eb7019d2f5275b35eb9e79f5306e8aab459e12aaa287ed02a module=libcontainerd namespace=moby topic=/tasks/delete type="*events.TaskDelete"
Aug 14 20:00:11 cap containerd: time="2025-08-14T20:00:11.621203827+08:00" level=warning msg="cleanup warnings time=\"2025-08-14T20:00:11+08:00\" level=info msg=\"starting signal loop\" namespace=moby pid=52083 runtime=io.containerd.runc.v2\n"
Aug 14 20:00:11 cap dockerd: time="2025-08-14T20:00:11.621741372+08:00" level=warning msg="ShouldRestart failed, container will not be restarted" container=90828a5018f0fc3eb7019d2f5275b35eb9e79f5306e8aab459e12aaa287ed02a daemonShuttingDown=false error="restart canceled" execDuration=11h59m59.316246392s exitStatus="{137 2025-08-14 12:00:11.579683933 +0000 UTC}" hasBeenManuallyStopped=true restartCount=0
Aug 14 20:00:11 cap avahi-daemon[1911]: Withdrawing address record for fe80::785f:e6ff:fe53:4e9c on veth4b6903b.
Aug 14 20:00:11 cap kernel: docker0: port 2(veth4b6903b) entered disabled state
Aug 14 20:00:11 cap kernel: docker0: port 2(veth4b6903b) entered disabled state
Aug 14 20:00:11 cap NetworkManager[1877]: <info>  [1755172811.6551] manager: (vethdec9609): new Veth device (/org/freedesktop/NetworkManager/Devices/250)
Aug 14 20:00:11 cap avahi-daemon[1911]: Withdrawing workstation service for vethdec9609.
Aug 14 20:00:11 cap kernel: device veth4b6903b left promiscuous mode
Aug 14 20:00:11 cap kernel: docker0: port 2(veth4b6903b) entered disabled state
Aug 14 20:00:11 cap avahi-daemon[1911]: Withdrawing workstation service for veth4b6903b.
Aug 14 20:00:11 cap NetworkManager[1877]: <info>  [1755172811.6667] device (veth4b6903b): released from master device docker0
Aug 14 20:00:11 cap journal: Removing a network device that was not added
Aug 14 20:00:11 cap libvirtd: 2025-08-14 12:00:11.670+0000: 2928: error : virFileReadAll:1460 : 打开文件 '/sys/class/net/vethdec9609/operstate' 失败: 没有那个文件或目录
Aug 14 20:00:11 cap libvirtd: 2025-08-14 12:00:11.670+0000: 2928: error : virNetDevGetLinkInfo:2552 : unable to read: /sys/class/net/vethdec9609/operstate: 没有那个文件或目录
Aug 14 20:00:11 cap journal: Removing a network device that was not added
Aug 14 20:00:11 cap kernel: docker0: port 2(veth916a435) entered blocking state
Aug 14 20:00:11 cap kernel: docker0: port 2(veth916a435) entered disabled state
Aug 14 20:00:11 cap kernel: device veth916a435 entered promiscuous mode
Aug 14 20:00:11 cap kernel: IPv6: ADDRCONF(NETDEV_UP): veth916a435: link is not ready
Aug 14 20:00:11 cap kernel: docker0: port 2(veth916a435) entered blocking state
Aug 14 20:00:11 cap kernel: docker0: port 2(veth916a435) entered forwarding state
Aug 14 20:00:11 cap NetworkManager[1877]: <info>  [1755172811.6883] manager: (vethbcc5924): new Veth device (/org/freedesktop/NetworkManager/Devices/251)
Aug 14 20:00:11 cap NetworkManager[1877]: <info>  [1755172811.6893] manager: (veth916a435): new Veth device (/org/freedesktop/NetworkManager/Devices/252)
Aug 14 20:00:11 cap containerd: time="2025-08-14T20:00:11.728945634+08:00" level=info msg="loading plugin \"io.containerd.event.v1.publisher\"..." runtime=io.containerd.runc.v2 type=io.containerd.event.v1
Aug 14 20:00:11 cap containerd: time="2025-08-14T20:00:11.729084477+08:00" level=info msg="loading plugin \"io.containerd.internal.v1.shutdown\"..." runtime=io.containerd.runc.v2 type=io.containerd.internal.v1
Aug 14 20:00:11 cap containerd: time="2025-08-14T20:00:11.729100825+08:00" level=info msg="loading plugin \"io.containerd.ttrpc.v1.task\"..." runtime=io.containerd.runc.v2 type=io.containerd.ttrpc.v1
Aug 14 20:00:11 cap containerd: time="2025-08-14T20:00:11.729349497+08:00" level=info msg="starting signal loop" namespace=moby path=/run/containerd/io.containerd.runtime.v2.task/moby/90828a5018f0fc3eb7019d2f5275b35eb9e79f5306e8aab459e12aaa287ed02a pid=52143 runtime=io.containerd.runc.v2
Aug 14 20:00:11 cap avahi-daemon[1911]: Withdrawing workstation service for vethbcc5924.
Aug 14 20:00:11 cap kernel: IPv6: ADDRCONF(NETDEV_CHANGE): veth916a435: link becomes ready
Aug 14 20:00:11 cap NetworkManager[1877]: <info>  [1755172811.9243] device (veth916a435): carrier: link connected
Aug 14 20:00:11 cap journal: Removing a network device that was not added
Aug 14 20:00:12 cap systemd: Removed slice User Slice of root.
Aug 14 20:00:13 cap avahi-daemon[1911]: Registering new address record for fe80::9894:70ff:fe7c:5e48 on veth916a435.*.

把日志扔给 deepseek 说是 docker 容器强制终止触发宿主机内核网络栈状态异常。请问有这个可能吗？我不是专业运维，请问一下大家， 如果 docker restart 指令确实会影响宿主机网络协议栈，目前我只想到了以下方案： 把 docker restart 指令改为 docker stop + sleep + docker start 确保容器正常停止。然后 docker network prune --filter "unitl=24h"清理一下无用网络。

[kingzleshe]

你容器如果没用 network host 就不应该会有影响，问题是为啥频繁需求重启……

[3573535]

我每天重启一次，备份数据，没遇见过这个问题

[c4923]

@kingzleshe 因为配置文件里有个选项要定时开启或者关闭，重启方便应用新的配置

[c4923]

@3573535 我也感觉邪门，我自己一直手动重启都是正常的，从没遇到过这个问题。只能认为是客户服务器的问题了。

[zy410692]

本人是个运维，我从来没有指望过 crontab 能定时运行

[c4923]

@zy410692 啊？那 Linux 做定时任务的话要怎么做？所幸 crontab 目前在我这里是正常的。不正常的只是 docker restart 。

[lhsakudsgdsik]

docker 是基于 daemon 机制的，出现这种玄学问题挺难查的，尤其是 20 版本之前，我之前就遇到过客户改了最外面的网络防火墙策略导致有个 docker 容器怎么都访问不了，其他的容器都正常，查了半天查不出来，怎么重启容器都不行，让客户把防火墙策略取消了也不行，最后重启整个 docker 可以解决，所以后面部署的环境都搞 podman 了，基于 systemd 启动容器

[c4923]

@lhsakudsgdsik 是的，我之前也遇到过几次更改防火墙配置导致容器出现问题。但是没办法， 目前我们这边还是只能用 docker 。后面我也看看你说的这种方式。

[zy410692]

@c4923 就是不知道什么时候不好用，也懒得排。直接找些任务系统，任务失败告警....这样这样

[skiy]

先创建一个 network ，再在服务中添加。这样不知道能不能解决这个问题 。

docker network create my-network
docker run --network my-network -d --name my-container nginx

[om2mo]

除了 host 模式容器有自己的网络栈，但我想说的是难道不应该容器里的程序重启吗而不是容器本身

[coefu]

为什么会有 libvirtd ？你不会在 kvm 的宿主机上跑了 docker daemon 吧？

[coefu]

我仔细看了 2 遍，你这个日志，docker 部分我没看到异常，相反是 libvirtd 有报错，应该是你自己定位不准确，或许宿主机网络栈出现过问题，但不是你这段日志里能暴露出来的。

[kingzleshe]

如果为了更新配置文件，干脆强制删除容器，然后 docker run 创建新的

[kingzleshe]

这样虚拟网卡也会有删除重建的动作，避免你的问题，虽然不知道是啥问题

[julyclyde]

@c4923
@zy410692
因为有些别的运维会关闭 crond
比如腾讯 teg/csig 的一些人

[julyclyde]

以你这个需求来说，你对容器技术的使用方法不对
配置文件和程序一样都是需要版本化管理的。你应该在每次配置文件变动的时候重新 build 一个 image 出来然后运行它

[jedihy]

毕竟有个 veth add/remove ，不可能毫无影响。要更加隔离可以在跑 docker 跑在 VM 里面。

[guanzhangzhang]

把 libvirtd daemon 关了，不用 ipv6 的话内核参数关闭 ipv6 ，配置下 networkManager 的子配置文件，新增一个忽略 veth 开头的网卡

[c4923]

@julyclyde 我知道要做配置文件的版本管理，但是公司在这方面还不完善，毕竟连专业运维都没有，只能用这种方式临时凑合一下

[c4923]

@guanzhangzhang 我去查一下看看

[tubowen]

是不是宿主机挂机，恢复过，之前在 UBUNtu 桌面版发现过，只要一挂起，再恢复，容器网络就会不正常，因为 network manager 挂起恢复后会变得不正常

[hancai2]

@c4923 不建议每次都去重启容器， 假定这次是网络原因，下次可能还会遇到其它原因， 比如楼上提到的 iptables 转发。不如从代码成面去解决读取配置的问题。

[hetal]

docker swarm 或者 docker compose 都可以很好的解决楼主的问题