Hacktoberfest 2026：维护者为十月标记出来的 issue，仍然开放、适合新手。 浏览 Hacktoberfest issue

ExApp container can't start after its network is recreated ("network ... not found", reported as container not found)

未关闭
  • 哪里不对？
#151 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 1 天内回复

还没有人认领这个 Issue。

评估

难度
4/5
预计耗时
3-5 天
新手友好度
48/100
Issue 类型
缺陷
描述清晰度
基本清楚
活跃度
活跃
技术栈
docker, docker-compose, python
领域
backend, infrastructure

调研方向

Start at docker_exapp_start, which the issue names as the handler that turns the Docker start failure into a misleading missing-container response. Trace how it starts containers and handles Docker API errors, then inspect the container and network connection flow by network name. Done means a recreated network lets the existing ExApp container start again, with a single retry, and unrelated 404 errors are not reported as missing containers.

由索引模型根据 Issue 内容生成。

描述

Steps to reproduce
  1. Register a HaRP daemon whose ExApps use a user-defined network (--net=<network>) that is owned by a compose project (e.g. HaRP and Nextcloud deployed with docker compose, the ExApp network being one of the project's networks).
  2. Install an ExApp, then disable it (its container is now stopped).
  3. Run docker compose down and docker compose up -d on the project (this also happens on a host reboot or on an app stop/start on platforms that manage the stack with compose, e.g. TrueNAS). Since no running container uses the network, compose removes it and creates a new one with the same name and a new ID.
  4. Enable the ExApp again.

Plain docker reproduction of the underlying behavior:

cat > compose.yaml <<'EOF'
services:
  a:
    image: alpine:3.20
    command: sleep infinity
    networks: [hn]
networks:
  hn:
    internal: true
EOF
docker compose -p repro up -d
docker run -d --name nc_app_repro --network repro_hn alpine:3.20 sleep infinity
docker stop nc_app_repro
docker compose -p repro down && docker compose -p repro up -d
docker start nc_app_repro
# Error response from daemon: failed to set up container networking: network 09ee65b4fa... not found
Expected behaviour

The ExApp starts, as its network (by name) still exists.

Actual behaviour

The container keeps the ID of the removed network, so every start fails and the ExApp never comes back: enabling never completes and Nextcloud reports the ExApp as unreachable. Only unregistering and registering the ExApp again (which recreates the container) recovers it.

The Docker Engine answers POST /containers/{name}/start with 404 {"message":"failed to set up container networking: network <id> not found"}, so docker_exapp_start logs Container '<name>' not found, cannot start. and returns 404 to AppAPI, which hides the real cause.

The container is recoverable without recreating it: docker network connect <network name> <container> on the stopped container replaces the stale endpoint (the network name is still the key under NetworkSettings.Networks in the container's inspect data), after which it starts normally.

Suggested handling in docker_exapp_start: when the start fails with network ... not found, inspect the container, reconnect it to its networks by name (POST /networks/{name}/connect) and retry the start once. At least, the 404 should not be reported as a missing container.

Server configuration

Platform: TrueNAS 27.0.0-RC.1 (Nextcloud app; Docker Engine, stack managed with docker compose)

HaRP version: v0.4.7

Nextcloud version: 35.0.2

Web server: Nginx

Database: PostgreSQL

Reproduced the Docker behavior locally on Docker Engine 29.8.2. Downstream report: https://github.com/truenas/apps/issues/6228

主要语言
Python
星标
56
派生
10
平均合并
13 小时 38 分钟
30 天内合并 PR
29

环境准备

  • 提供 Dockerfile 或 Docker Compose 文件
  • 没有 Pull Request 模板
  • 阅读贡献指南

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

nextcloud/HaRP 的其他 Issue

查看 nextcloud/HaRP 的全部 Issue

相似的 Issue

更多 Python Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。