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
Calling container.stop() asks the container to stop, and will block for a given timeout (which by default is 0). If a container takes a long time to stop, or ignores a SIGTERM, then it will continue to run, even after being asked to stop.
We cannot make container.stop() also kill the container, because some containers need to be interacted with after it's been stopped (e.g a Selenium container to copy the recordings from).
Therefore we could add a separate kill method to the StartedTestContainer which users can call in cases where the container does not gracefully stop.
The text was updated successfully, but these errors were encountered:
Looking into this a bit more, Docker should automatically kill the container when the stop timeout elapses, meaning this is unnecessary. Found this issue which implies a potential regression with Docker on Ubuntu redis/docker-library-redis#386. Need more info to reproduce.
Calling
container.stop()
asks the container to stop, and will block for a given timeout (which by default is0
). If a container takes a long time to stop, or ignores a SIGTERM, then it will continue to run, even after being asked to stop.We cannot make
container.stop()
also kill the container, because some containers need to be interacted with after it's been stopped (e.g a Selenium container to copy the recordings from).Therefore we could add a separate
kill
method to theStartedTestContainer
which users can call in cases where the container does not gracefully stop.The text was updated successfully, but these errors were encountered: