You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When attempting to run a batch-mode dockerized program, it is very useful to use the wait condition to wait for a zero exit status and follow mode on. In my case, this would be for running a local Hadoop program, but it could also be employed for other dockerizable tools.
However, if the build is interrupted by the user with control-C, instead of killing the container, it leaves it running disconnected in the background. This appears to be because the wait condition has not yet been satisfied, and so the stop container logic is not active.
The fix, I think, is to simply move the registration of the shutdown hook ahead of starting any of the containers when in follow mode.
Info
d-m-p version : 0.23.0
Maven version (mvn -v) : 3.5.2
Docker version : 1.12.6
If it's a bug, how to reproduce :
Start a container with a wait condition that will not be satisfied quickly and follow mode enabled (docker:run, for example).
Abort the build with control-C.
Observe that the container is not stopped or removed.
The text was updated successfully, but these errors were encountered:
scoplin
pushed a commit
to scoplin/docker-maven-plugin
that referenced
this issue
Jan 2, 2018
Moves the shutdown hook in the StartMojo earlier so that containers that
will be cleaned up even if they haven't been fully started per their
wait conditions. This is especially likely to occur on aborted builds.
[fixesfabric8io#921]
Signed-off-by: Scott Coplin <[email protected]>
Description
When attempting to run a batch-mode dockerized program, it is very useful to use the wait condition to wait for a zero exit status and follow mode on. In my case, this would be for running a local Hadoop program, but it could also be employed for other dockerizable tools.
However, if the build is interrupted by the user with control-C, instead of killing the container, it leaves it running disconnected in the background. This appears to be because the wait condition has not yet been satisfied, and so the stop container logic is not active.
The fix, I think, is to simply move the registration of the shutdown hook ahead of starting any of the containers when in follow mode.
Info
mvn -v
) : 3.5.2docker:run
, for example).The text was updated successfully, but these errors were encountered: