-
Notifications
You must be signed in to change notification settings - Fork 578
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
[universal] Avoid invoking {docker,ssh}-init.sh twice #1240
Conversation
5822e50
to
7aadc4d
Compare
7aadc4d
to
811ec67
Compare
This is both a fix and a simplification. It's a simple change (simply remove the `ENTRYPOINT` from the Dockerfile, but understanding why it's correct needs a bit of context: In a devcontainer with `overrideCommand`=_true_ (which should be the default according to the devcontainers documentation, but actually isn't in GitHub Codespaces—more on that further down), this `ENTRYPOINT` isn't used and hasn't actually been needed for quite a while [1], as devcontainer features can supply additional entrypoints that are always run regardless of `overrideCommand` [2]. These are stored in the image metadata that the devcontainers CLI fetches and respects: $ regctl image inspect --format='{{json .}}' -- \ mcr.microsoft.com/devcontainers/universal:2 \ | jq -r '.config.Labels."devcontainer.metadata"' \ | jq -r '.[].entrypoint | select(.)' /usr/local/share/ssh-init.sh /usr/local/share/docker-init.sh [1]: https://github.com/microsoft/vscode-docs/blob/424848fa6b6c3382ae341fecdbe08df561f1c961/remote-release-notes/v1_64.md?plain=1#L5 [2]: https://github.com/devcontainers/cli/blob/7178cebfa88e070439903fd975b7602e7b3f6dc7/src/spec-node/singleContainer.ts#L387-L399 The init process (pid 1) in such a container looks like this, which is exactly what is desired, as the entrypoints are invoked in sequence, each once: $ < /proc/1/cmdline xargs -0 printf "%q\n" /sbin/docker-init -- /bin/sh -c 'echo Container started'$'\n''trap "exit 0" 15'$'\n''/usr/local/share/ssh-init.sh'$'\n''/usr/local/share/docker-init.sh'$'\n''exec "$@"'$'\n''while sleep 1 & wait $!; do :; done' - Now if one creates a devcontainer from the universal image with `overrideCommand`=_false_ on the other hand, the init process command line looks a bit different: $ < /proc/1/cmdline xargs -0 printf "%q\n" /sbin/docker-init -- /bin/sh -c 'echo Container started'$'\n''trap "exit 0" 15'$'\n''/usr/local/share/ssh-init.sh'$'\n''/usr/local/share/docker-init.sh'$'\n''exec "$@"'$'\n''while sleep 1 & wait $!; do :; done' - /usr/local/share/docker-init.sh /usr/local/share/ssh-init.sh sleep infinity In addition to invoking the entrypoints from the docker image metadata (see above), the `exec "$@` bit invokes the `ENTRYPOINT` and `CMD` from the universal Dockerfile. This results in both docker-init.sh and ssh-init.sh being invoked twice during container startup. The ssh-init.sh script happens to handle this gracefully. It uses `start-stop-daemon … --start --pidfile /run/sshd.pid …` which does nothing if the process is running already. The other one, docker-init.sh, isn't as smart unfortunately. The first thing it does is it forcefully removes all `docker*.pid` and `container*.pid` regardless of whether any dockerd/containerd is running, then starts a new dockerd, then checks whether the daemon starts healthy, and proceeds to pkill everything and repeat if not. A typical universal image devcontainer startup thus looks like this: 1. ssh-init.sh runs for the first time 2. sshd is started 3. docker-init.sh runs for the frist time 4. dockerd is started 5. after some wait, dockerd is considered healthy, docker-init.sh exits 6. ssh-init.sh runs again, but that's a no-op 7. docker-init.sh runs again 8. dockerd.pid and containerd.pid are removed 9. dockerd is started again, so we have two dockerd instances 10. docker info no longer considers the daemon healthy 11. after 5 attempts to determine dockerd health, it gives up 12. pkill dockerd/containerd which kills both instances 13. start dockerd again 14. try docker info again 15. this time it finally succeeds, but oh god it's taken a while! The final piece of the puzzle is understanding how I ended up with `overrideCommand`=_false_ in the first place. Truth be told, I don't quite fully understand this yet. All I've done is used the following devcontainer.json in GitHub Codespaces: { "name": "my first slightly disappointing devcontainer", "image": "mcr.microsoft.com/devcontainers/universal:2", } The proprietary code (they call it the "agent"?) that sets up the devcontainer in GitHub Codespaces creates `/workspaces/.codespaces/shared/merged_devcontainer.json` with the mounts and capabilities and other environment-specific additions. For reasons I don't yet understand (but I'm waiting for GitHub Support to explain), it also sets `overrideCommand` to _false_. And it only seems to do it if the universal image is used, it's kept at its default value if one happens to use e.g. `mcr.microsoft.com/devcontainers/base:1-bookworm`. I mean, the change in this commit makes sense even in the absence of this weird behaviour of GitHub Codespaces. But it does mean that this likely affects other people using the universal image, and should be fixed sooner rather than never.
811ec67
to
94db160
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This fix makes sense to me! I'm not too familiar with why we set the overrideCommand
in the Codespaces agent for the Universal image, but we can remove that since these scripts are being run from the features anyway like you say. Thanks!
Am I expected to deal with the failing Smoke test? The failure seems unrelated to my changes and the same is happening on the main branch as well. |
@liskin nope you're good, I just checked and it seems to be failing on most runs. I'll bring it up to the team but no need to block this PR on it. Merging now |
This is both a fix and a simplification. It's a simple change (simply remove the
ENTRYPOINT
from the Dockerfile, but understanding why it's correct needs a bit of context:In a devcontainer with
overrideCommand
=true (which should be the default according to the devcontainers documentation, but actually isn't in GitHub Codespaces—more on that further down), thisENTRYPOINT
isn't used and hasn't actually been needed for quite a while 1, as devcontainer features can supply additional entrypoints that are always run regardless ofoverrideCommand
2. These are stored in the image metadata that the devcontainers CLI fetches and respects:The init process (pid 1) in such a container looks like this, which is exactly what is desired, as the entrypoints are invoked in sequence, each once:
Now if one creates a devcontainer from the universal image with
overrideCommand
=false on the other hand, the init process command line looks a bit different:In addition to invoking the entrypoints from the docker image metadata (see above), the
exec "$@
bit invokes theENTRYPOINT
andCMD
from the universal Dockerfile. This results in both docker-init.sh and ssh-init.sh being invoked twice during container startup.The ssh-init.sh script happens to handle this gracefully. It uses
start-stop-daemon … --start --pidfile /run/sshd.pid …
which does nothing if the process is running already.The other one, docker-init.sh, isn't as smart unfortunately. The first thing it does is it forcefully removes all
docker*.pid
andcontainer*.pid
regardless of whether any dockerd/containerd is running, then starts a new dockerd, then checks whether the daemon starts healthy, and proceeds to pkill everything and repeat if not. A typical universal image devcontainer startup thus looks like this:The final piece of the puzzle is understanding how I ended up with
overrideCommand
=false in the first place. Truth be told, I don't quite fully understand this yet. All I've done is used the following devcontainer.json in GitHub Codespaces:The proprietary code (they call it the "agent"?) that sets up the devcontainer in GitHub Codespaces creates
/workspaces/.codespaces/shared/merged_devcontainer.json
with the mounts and capabilities and other environment-specific additions. For reasons I don't yet understand (but I'm waiting for GitHub Support to explain), it also setsoverrideCommand
to false. And it only seems to do it if the universal image is used, it's kept at its default value if one happens to use e.g.mcr.microsoft.com/devcontainers/base:1-bookworm
.I mean, the change in this commit makes sense even in the absence of this weird behaviour of GitHub Codespaces. But it does mean that this likely affects other people using the universal image, and should be fixed sooner rather than never.