[universal] Avoid invoking {docker,ssh}-init.sh twice

[liskin]

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

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.