mirror of
https://github.com/GNS3/gns3-server.git
synced 2026-09-06 18:17:03 +03:00
42 lines
1.7 KiB
Markdown
42 lines
1.7 KiB
Markdown
---
|
|
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]]
|