Problem
When imposter up starts a mock but the engine never becomes healthy within the start timeout, WaitForOp in internal/engine/health.go (~line 114) calls logger.Fatalf("timed out waiting for %s", ...), which terminates the CLI process immediately via os.Exit.
Because the CLI exits without going through engine shutdown:
- JVM / Golang engines: the mock is a child process started via
exec.Cmd. On os.Exit the child is not killed — it is reparented to init/launchd and keeps running (or keeps failing/looping) in the background, orphaned.
- Docker engine: the container has already been created and started in the Docker daemon, so it keeps running after the CLI exits.
In both cases the user is left with a stray mock that they must manually clean up (imposter down / docker rm), with no indication from the failed up invocation that anything is still running.
Expected behaviour
On healthcheck timeout, imposter up should stop/remove the mock it just started before exiting non-zero, so a failed start does not leak a running process or container.
Notes
- Discovered while planning the
--detach feature. The --detach=healthy mode relies on the same WaitUntilUp/WaitForOp path, so it inherits this behaviour; tracking the underlying cleanup-on-timeout problem here as a separate, pre-existing bug rather than fixing it as part of the detach work.
- Relevant code:
internal/engine/health.go WaitForOp/WaitUntilUp; engine Start/Stop in internal/engine/{jvm,golang,docker}/engine.go.
Problem
When
imposter upstarts a mock but the engine never becomes healthy within the start timeout,WaitForOpininternal/engine/health.go(~line 114) callslogger.Fatalf("timed out waiting for %s", ...), which terminates the CLI process immediately viaos.Exit.Because the CLI exits without going through engine shutdown:
exec.Cmd. Onos.Exitthe child is not killed — it is reparented to init/launchd and keeps running (or keeps failing/looping) in the background, orphaned.In both cases the user is left with a stray mock that they must manually clean up (
imposter down/docker rm), with no indication from the failedupinvocation that anything is still running.Expected behaviour
On healthcheck timeout,
imposter upshould stop/remove the mock it just started before exiting non-zero, so a failed start does not leak a running process or container.Notes
--detachfeature. The--detach=healthymode relies on the sameWaitUntilUp/WaitForOppath, so it inherits this behaviour; tracking the underlying cleanup-on-timeout problem here as a separate, pre-existing bug rather than fixing it as part of the detach work.internal/engine/health.goWaitForOp/WaitUntilUp; engineStart/Stopininternal/engine/{jvm,golang,docker}/engine.go.