so I think I found a bad behavior in how the docker_environment works in pants. Given the following: 1. A pants package is run and a docker environment is started up. 2. The running container is then used to run the target which specifies the docker_environment to run from 3. When a target is exited by using a ^C the docker container remains running 4. Killing the docker container using

docker rm -f <container_name>

is then run 5. Next, when the

pants package ::

command is next run, the container is no longer running and you get the following error

Failed to create Docker execution in container: DockerResponseServerError { status_code: 404, message: "No such container: db9353edd494b26ff36a9603f22715ad32e16bb74fdb410b0747d9eabacb853b" }

Given that it is entirely possible that the docker stack may need to be restarted, or the container killed, it seems that a more graceful mechanism is needed here.

For background on 3: pants has a background daemon process ("pantsd"), that is intentionally managing the container persistently, so that future jobs that need it can use it directly, without having to start a new one. You're definitely correct that the behaviour in 5 is not good, https://github.com/pantsbuild/pants/issues/18209 . To work-around this for now, you can force the creation of a new pantsd daemon tostart a new container by killing the old one:

pkill -f pantsd

.

Yeah, this is tricky, pantsd maintains state, which usually is just files, but when working with docker some of that state is in the docker daemon.

Note, killing and restarting pantsd doesn't clear that container state. I've had to manually delete the .pids directory to get things cleared.