-
Notifications
You must be signed in to change notification settings - Fork 618
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
oci runtime error: container_linux.go:247: starting container process caused "process_linux.go:359: container init caused... #951
Comments
@KensoDev Can you provide more details regarding the environment, what's the docker version and ecs-agent version? I don't think this was caused by that one mount points inside another mount point, as I tried the following task-definition which works fine for me on both ECS Optmized AMI(17.03.1-ce) and ubuntu(17.05.0-ce) , were you able to use the ecs-agent to launch other task and can you also share me with a task-definition that can reproduce this problem?
Can you also check the permission about the directory
Thanks, |
So. I reproduced this again just now here's the task definition (only things marked REDACTED) are names. Other than that it is verbatim our deployed definition The error:
AMI
Task definition:
Cluster docker information:
|
@KensoDev Thanks for providing the information, but I didn't see the task definition, did you forget to paste here or you send it somewhere else? Edit, looks like there is some delay, I saw it now, will verify and get back to you. Thanks! |
@richardpen I added all the information you asked for. Let me know if something else is unclear. |
@richardpen task definition pasted in the comment |
Here it is again
|
Strange that this would seem to have different symptoms based on region. The Ubuntu release and docker version are identical? There are no regional variances in the ECS Agent; the binary is identical for all regions. |
@nmeyerhans This threw me off the most as well. us-east - once I run the docker container once manually. the scheduler will pick it up and continue working TBH, this is what led me to debug this more since I had a recovery path on the other env that I could easily "bypass" the bug with. |
@KensoDev Sorry for the late response, I can reproduce this issue with the provided task definition. But if you removed the line The reason here is that you have a nested mount path: Please let us know if that solves your problem, thanks. |
I resolved it another way but not nesting it under one another, but I would certainly imagine that this will solve the issue. |
Summary
When trying to run a container with mounted volumed under ECS. Got this error. This is going to be a very detailed report since we got this error many times and debugged it to resolution.
Description
When trying to run a container with mounted volumes under ECS, got this error
Now, this has 2 symptoms, different on us-east-1 and us-west-2
us-east-1
After running the container manually on one of the instances in the cluster, the scheduler was able to recover and schedule containers across the cluster.
us-west-2
Even when running the container manually, it was not able to recover.
uname -a
uname -a
Container configuration
mount points
As you can see, one of the mount points is mapped internally to another mount point. You have
/etc/nginx
and/etc/nginx/sites-enabled
.When doing this with
docker run
manually, it had no issues. Not on west and not on east which is what took a long time to debug and understand. This only happened through the scheduler.Also tracked: #658 and under runc.
I started taking a look into the code. Maybe warning the scheduler and outputting an error that will say the child paths cannot be mounted will be helpful.
More data points.
The text was updated successfully, but these errors were encountered: