ExApp container can't start after its network is recreated ("network ... not found", reported as container not found)
Maintainer thường phản hồi trong vòng 1 ngày
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 4/5
- Thời gian dự kiến
- 3-5 ngày
- Mức phù hợp với người mới
- 48/100
- Loại issue
- Lỗi
- Độ rõ ràng
- Khá rõ ràng
- Mức độ hoạt động
- Sôi nổi
- Công nghệ
- docker, docker-compose, python
- Lĩnh vực
- backend, infrastructure
Hướng nghiên cứu
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.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
Steps to reproduce
- 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). - Install an ExApp, then disable it (its container is now stopped).
- Run
docker compose downanddocker compose up -don 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. - 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
- Ngôn ngữ chính
- Python
- Star
- 56
- Fork
- 10
- Merge trung bình
- 13 giờ 38 phút
- Pull request đã merge (30 ngày)
- 29
Chuẩn bị môi trường
- Có Dockerfile hoặc tệp Docker Compose
- Không có mẫu pull request
- Đọc hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của nextcloud/HaRP
-
Độ khó 3/5 1-2 ngày Mức phù hợp với người mới 68/100
nextcloud/HaRP#114 · 2 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
ExApps FRP download issue trackĐang mở
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 25/100
Maintainer thường phản hồi trong vòng 1 ngày
-
bug ExApp issue
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 35/100
nextcloud/HaRP#61 · 1 bình luận · 1 reaction ·
Maintainer thường phản hồi trong vòng 1 ngày
-
bug
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 32/100
nextcloud/HaRP#50 · 3 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
enhancement
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 25/100
nextcloud/HaRP#49 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
Tất cả issue của nextcloud/HaRP
Issue tương tự
-
intake mcp-intake needs-ac needs-human-review priority:medium
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 67/100
Ikalus1988/MisakaNet#3848 · 2 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 75/100
521xueweihan/HelloGitHub#4105 ·
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 75/100
igormcsouza/bookloud#54 ·
-
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 90/100
aws-samples/sample-per-model-bedrock#526 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
ok-oldking/ok-wuthering-waves#1802 ·
Maintainer thường phản hồi trong vòng 2 ngày