这是一个创建于 55 天前的主题，其中的信息可能已经有所发展或是发生改变。
问题：因业务需求，我在 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"清理一下无用网络。
24 条回复 2025-08-18 14:44:39 +08:00
 | 1 kingzleshe 55 天前 你容器如果没用 network host 就不应该会有影响，问题是为啥频繁需求重启…… |
 | 2 3573535 55 天前 via iPhone 我每天重启一次，备份数据，没遇见过这个问题 |
 | 3 c4923 OP @kingzleshe 因为配置文件里有个选项要定时开启或者关闭，重启方便应用新的配置 |
 | 5 zy410692 55 天前  3 本人是个运维，我从来没有指望过 crontab 能定时运行 |
 | 7 lhsakudsgdsik 55 天前 docker 是基于 daemon 机制的，出现这种玄学问题挺难查的，尤其是 20 版本之前，我之前就遇到过客户改了最外面的网络防火墙策略导致有个 docker 容器怎么都访问不了，其他的容器都正常，查了半天查不出来，怎么重启容器都不行，让客户把防火墙策略取消了也不行，最后重启整个 docker 可以解决，所以后面部署的环境都搞 podman 了，基于 systemd 启动容器 |
| 8 c4923 div class="badges">OP 55 天前 @lhsakudsgdsik 是的，我之前也遇到过几次更改防火墙配置导致容器出现问题。但是没办法， 目前我们这边还是只能用 docker 。后面我也看看你说的这种方式。 |
 | 10 skiy 55 天前 先创建一个 network ，再在服务中添加。这样不知道能不能解决这个问题 。 docker network create my-network docker run --network my-network -d --name my-container nginx |
 | 11 om2mo 55 天前 via Android 除了 host 模式容器有自己的网络栈，但我想说的是难道不应该容器里的程序重启吗而不是容器本身 |
 | 12 coefu 55 天前 为什么会有 libvirtd ？你不会在 kvm 的宿主机上跑了 docker daemon 吧？ |
| 13 coefu 55 天前 1 我仔细看了 2 遍，你这个日志，docker 部分我没看到异常，相反是 libvirtd 有报错，应该是你自己定位不准确，或许宿主机网络栈出现过问题，但不是你这段日志里能暴露出来的。 |
| 14 kingzleshe 55 天前 如果为了更新配置文件，干脆强制删除容器，然后 docker run 创建新的 |
| 15 kingzleshe 55 天前 这样虚拟网卡也会有删除重建的动作，避免你的问题，虽然不知道是啥问题 |
 | 17 julyclyde 55 天前 以你这个需求来说，你对容器技术的使用方法不对 配置文件和程序一样都是需要版本化管理的。你应该在每次配置文件变动的时候重新 build 一个 image 出来然后运行它 |
 | 18 jedihy 54 天前 毕竟有个 veth add/remove ，不可能毫无影响。要更加隔离可以在跑 docker 跑在 VM 里面。 |
 | 19 guanzhangzhang 53 天前 把 libvirtd daemon 关了，不用 ipv6 的话内核参数关闭 ipv6 ，配置下 networkManager 的子配置文件，新增一个忽略 veth 开头的网卡 |
| 21 c4923 OP @guanzhangzhang 我去查一下看看 |
 | 22 tubowen 52 天前 via Android 是不是宿主机挂机，恢复过，之前在 UBUNtu 桌面版发现过，只要一挂起，再恢复，容器网络就会不正常，因为 network manager 挂起恢复后会变得不正常 |
 | 24 hetal 52 天前 docker swarm 或者 docker compose 都可以很好的解决楼主的问题 |
Select Language