gns3-server/.claude/memory/docker-container-stop-delay.md

name, description, metadata

name	description	metadata
docker-container-stop-delay	Docker containers not responding to SIGTERM cause ~5s stop delays when closing a project	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