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
While doing work on getting Gitlab CI runners operational with Triton Docker, I came across an issue whereby the use of the attach endpoints (programatically and through the docker client binaries) would not make any progress.
As some background, the strategy that Gitlab uses with Docker containers is:
Create the container with OpenStdin: true and StdinOnce: true and tty: false. The command supplied to the container is /bin/bash or some equivalent shell
Start the container
Attach to the container and execute the build command
Wait for the container to exit
The container should automatically exit once the 'Attach' step is complete, as per StdinOnce being set to true. On the normal Docker Engine, running on my local OS X (via Docker for Mac), this is what happens. When performing this against both JPC and a private Triton installation operating on the latest release sdc-docker, the attach call successfully connects (calling docker attach elsewhere results in a zlogin error about it already being in use) but it seems that stdin is not consumed. As such, the attach call just hangs and eventually times out.
I've yet to perform sdc-docker tracing against this problem, but a quick overview of the logs show the connection entering the half-closed state and then there are no more entries.
I've written a small test program here that demonstrates the problem. It requires a local Docker of Mac installation and the Makefile needs to be modified to point to the docker certs folder, but that is detailed in that repo.
An example from that test program of the divergence, which is done against an ubuntu:16.10 container running with settings created as per the first step noted above. The program attaches to the container, supplies 'echo "Working"' over stdin and pipes the stdout/stderr of the container (via attach) to the programs stdout/err.
Docker Engine:
Pulling Image
Image Pulled - Building Container
Built Container with ID 743a8b6cf1abf83f4dea5f307b0a71360080e10c681cf722e96f88342ae3404f
Starting Container
Container started - Attaching
Working
Attachment complete - Waiting for Container to Exit
Exit Code (which should be 0) 0
Removing container
sdc-docker:
Pulling Image
Image Pulled - Building Container
Built Container with ID 743a8b6cf1abf83f4dea5f307b0a71360080e10c681cf722e96f88342ae3404f
Starting Container
Container started - Attaching
Once attached, sdc-docker makes no forward progress and eventually times out.
I'll update this issue with any more details that I find after tracing (aiming to collect packet dumps)
The text was updated successfully, but these errors were encountered:
While doing work on getting Gitlab CI runners operational with Triton Docker, I came across an issue whereby the use of the attach endpoints (programatically and through the docker client binaries) would not make any progress.
As some background, the strategy that Gitlab uses with Docker containers is:
The container should automatically exit once the 'Attach' step is complete, as per StdinOnce being set to true. On the normal Docker Engine, running on my local OS X (via Docker for Mac), this is what happens. When performing this against both JPC and a private Triton installation operating on the latest release sdc-docker, the attach call successfully connects (calling docker attach elsewhere results in a zlogin error about it already being in use) but it seems that stdin is not consumed. As such, the attach call just hangs and eventually times out.
I've yet to perform sdc-docker tracing against this problem, but a quick overview of the logs show the connection entering the half-closed state and then there are no more entries.
I've written a small test program here that demonstrates the problem. It requires a local Docker of Mac installation and the Makefile needs to be modified to point to the docker certs folder, but that is detailed in that repo.
An example from that test program of the divergence, which is done against an ubuntu:16.10 container running with settings created as per the first step noted above. The program attaches to the container, supplies 'echo "Working"' over stdin and pipes the stdout/stderr of the container (via attach) to the programs stdout/err.
Docker Engine:
sdc-docker:
Once attached, sdc-docker makes no forward progress and eventually times out.
I'll update this issue with any more details that I find after tracing (aiming to collect packet dumps)
The text was updated successfully, but these errors were encountered: