[BUG] Attached `up` never exits after external `stop`+`down` when a container is in restart backoff (regression in v2.39.3)

[otomon10]

Description

Since Compose v2.39.3, an attached docker compose up never exits when the project is stopped externally (docker compose stop + docker compose down from another process) while one of the containers is in restart backoff (Status=restarting with restart: unless-stopped).

Up to v2.39.2 the attached up exited a few seconds after down completed. From v2.39.3 on it hangs forever, even though all containers are stopped and removed. The behavior is still present in v5.3.1 (latest at the time of writing).

The apparent mechanism, observed via docker events during the stop window:

• a container that is stopped while it is in restart backoff emits only stop → destroy events — there is no die event, because no process is running at that moment;
• containers that are running normally when stopped emit the full kill → stop → die → destroy sequence;
• since v2.39.3 (detect container is restarted #13210), the attached up appears to wait for a die event per container to detect termination, so it waits forever for the container that never emits one.

This matters for supervisors that spawn an attached up as a child process and stop the project externally: the leftover up process keeps holding resources it inherited (in our case, flock file locks on the compose files taken by a wrapper), long after the project is gone.

Steps To Reproduce

docker-compose.yml:

services:
  crasher:
    image: busybox:latest
    command: ["false"]
    restart: unless-stopped
  sleeper:
    image: busybox:latest
    command: ["sleep", "3600"]

1. docker compose -p repro up --remove-orphans --force-recreate & (attached, in background)
2. Wait until the crasher is in restart backoff: docker inspect repro-crasher-1 --format '{{.State.Status}} {{.RestartCount}}' shows restarting with RestartCount >= 5
3. From another shell: docker compose -p repro stop -t 5 && docker compose -p repro down -t 5
4. Observe the backgrounded up process:
   • v2.39.2 and earlier: exits within a few seconds after down
   • v2.39.3 and later (incl. v5.0.2, v5.3.1): never exits (waited 120+ s)

Bisect over official release binaries (same engine, same procedure, PASS = up exits / FAIL = up hangs):

version	result
v2.15.1	PASS
v2.26.0	PASS
v2.33.1	PASS
v2.37.3	PASS
v2.38.2	PASS
v2.39.0	PASS
v2.39.1	PASS
v2.39.2	PASS
v2.39.3	FAIL (first bad release)
v2.39.4	FAIL
v5.0.2	FAIL
v5.3.1	FAIL

We also verified on a separate machine (same engine v29.3.0) that swapping only the compose CLI plugin between v5.0.2 and v2.38.2 toggles the hang with an identical docker events sequence, so the regression is in compose, not in the engine.

Compose Version

Docker Compose version v5.0.2
(also reproduced with v2.39.3, v2.39.4, v5.3.1; not reproducible with v2.39.2 and earlier)

Docker Environment

Reproduced on:
- Docker Engine 29.6.2 (amd64, WSL2) — bisect environment
- Docker Engine 29.3.0 (amd64, embedded Linux device) — production environment
Client: docker compose CLI plugin, official release binaries

Anything else?

The first bad release v2.39.3 contains #13210 ("use events to detect container exit"), which matches the observed mechanism (no die event is emitted for a container stopped during restart backoff).

Possibly related: moby/moby#50908 (open) adds a restarting attribute to die events for #13210's event-based detection. However, in this scenario the container emits no die event at all (only stop → destroy), so the attribute alone would not cover this case.

[andreimotin]

your event-level diagnosis is complete (destroy without die since #13210 is the whole bug), so just two architectural notes from building the same shape of thing: attaching is the fragile half of the design. up -d plus a separate docker compose events stream gives the supervisor the same visibility without a child process whose exit depends on compose's per-container die bookkeeping, and it means a wedged process can never inherit and hold your flocks, because nothing long-lived holds them. and for the locks themselves, flock -w <timeout> instead of a blocking flock turns this failure mode from a permanent deadlock into a logged, recoverable error, which is what a supervisor wants anyway.

glours' #13990 already treats destroy as terminal in the up monitor, so the compose side is moving. the supervisor-side lesson is the part that outlives the fix: a wedged child that can't exist beats one you have to detect.

dev line: i build a mac app that is roughly the grown-up version of the supervisor you're writing, it watches the containers and the daemon, diagnoses what died and why, and sends the fix to your phone to approve. free beta, demo: https://youtu.be/bx_OhpNysiM