From fb1a5a3385a65a9adff230bf0c866bb1a5fb78ad Mon Sep 17 00:00:00 2001
From: YueGuobin <yueguobin@outlook.com>
Date: Wed, 3 Jun 2026 22:47:48 +0800
Subject: [PATCH] Add project memory: Docker container stop delay analysis

---
 .claude/memory/MEMORY.md                      |  3 ++
 .claude/memory/docker-container-stop-delay.md | 41 +++++++++++++++++++
 2 files changed, 44 insertions(+)
 create mode 100644 .claude/memory/docker-container-stop-delay.md

diff --git a/.claude/memory/MEMORY.md b/.claude/memory/MEMORY.md
index 62343521b..9050f7d54 100644
--- a/.claude/memory/MEMORY.md
+++ b/.claude/memory/MEMORY.md
@@ -24,3 +24,6 @@
 
 ### uBridge Permission
 - **[uBridge Permission Issue](./gns3-ubridge-permission.md)** - Docker containers fail to start due to missing CAP_NET_ADMIN/CAP_NET_RAW capabilities on uBridge
+
+### Docker Container Stop Delay
+- **[Docker Container Stop Delay](./docker-container-stop-delay.md)** - Some containers take ~5s to stop because they don't handle SIGTERM (AlpiNet, OstinatoWireshark)
diff --git a/.claude/memory/docker-container-stop-delay.md b/.claude/memory/docker-container-stop-delay.md
new file mode 100644
index 000000000..ce38b8d20
--- /dev/null
+++ b/.claude/memory/docker-container-stop-delay.md
@@ -0,0 +1,41 @@
+---
+name: docker-container-stop-delay
+description: Docker containers not responding to SIGTERM cause ~5s stop delays when closing a project
+metadata:
+  type: reference
+---
+
+# Docker Container Stop Delay Analysis
+
+## Background
+When stopping a GNS3 project, some Docker containers take ~5s to exit while others stop instantly.
+
+## Root Cause
+Docker's `stop` command sends SIGTERM and waits `t` seconds (GNS3 sets `t=5`) before sending SIGKILL. Containers that don't handle SIGTERM are stuck waiting for the full timeout.
+
+## Affected Containers
+
+| Container | PID 1 | Why it's slow |
+|-----------|-------|---------------|
+| **AlpiNet** (alpine) | `dumb-init` → `bash -i` | Interactive bash ignores SIGTERM by design |
+| **OstinatoWireshark** | `bash` (PID 1) | Linux kernel won't apply default signal actions to PID 1 without an explicit handler; interactive bash doesn't install one |
+
+## Normal Containers (for comparison)
+
+| Container | PID 1 | Why fast |
+|-----------|-------|----------|
+| Chromium | `/usr/bin/chromium` | Chromium handles SIGTERM natively |
+| webterm | `dumb-init` → firefox | Firefox responds to SIGTERM immediately |
+
+## Related Files
+- `gns3-registry/docker/alpinet/Dockerfile`
+- `gns3-registry/docker/ostinato-wireshark/Dockerfile`
+- `gns3-registry/docker/ostinato-wireshark/entry.sh`
+- `gns3-registry/docker/chromium/Dockerfile`
+- `gns3-registry/docker/ipterm/web/Dockerfile`
+- `gns3-server/gns3server/compute/docker/docker_vm.py:1040` — stop timeout parameter `t=5`
+
+## Note
+This is not a GNS3 server bug (except a minor `or` vs `and` logic issue at `docker_vm.py:1037` which doesn't affect behavior). The root cause is in the Docker images themselves.
+
+See also: [[docker-container-stop-delay]]