-
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[blocker] adb defunct kills docker daemon on host #86
Comments
I can imagine that this is the problem The healtcheck seems to be restarted as soon as adb is having troubles (tried to run
@butomo1989 do you know why healthcheck strikes back? Reading the line of code it should exit after being healthy and never return. |
I think I found a problem and the fix in #89 Bad thing that this doesn't explain why emulator stops (probably just because of the natural reasons like crash, maybe we can have an monit or something else running in the container to wake it up) Good thing is that at least docker will not die anymore. |
Fixed in release 1.2 |
Operating System:
Debian 8
Docker Image:
butomo1989/docker-android-x86-7.1.1
Docker Version:
17.12.1-ce
Docker Command to start docker-android:
Running everything through Rancher
Expected Behavior
When running the containers for some hours or days they should keep running stable.
Actual Behavior
After a while (sometimes hours sometimes days) I noticed that quite a few of our containers for automated testing (>40 instanced) started to show a huge amount of defunct adb processes in each container. This usually leads to the point that the whole docker daemon on the host gets killed, the host becomes unusable for all docker containers, independently of running privileged or not, and the daemon on the host gets so messed up that it even cannot be restarted any more as it simply locks up and refuses to start, stop or operate in any way. So the only way out is to hard restart the host by turining the power off and on.
Because of this the containers cannot be used in our environment since we have quite a few huge tests that might run for a while and while running the container starts acting this way tearing down the host.
The text was updated successfully, but these errors were encountered: