docker, tini: link docker-init statically to fix docker run --init

[dcasota]

Problem

docker run --init (and compose init: true) fails on any container whose rootfs has no glibc loader:

exec /sbin/docker-init: no such file or directory

/sbin/docker-init is not a host path. It is the hardcoded in-container destination. From moby daemon/oci_linux.go:

const inContainerInitPath = "/sbin/" + dconfig.DefaultInitBinary  // "/sbin/docker-init"

s.Process.Args = append([]string{inContainerInitPath, "--", c.Path}, c.Args...)
path, err := daemonCfg.LookupInitPath() // resolves the HOST binary
s.Mounts = append(s.Mounts, specs.Mount{
    Destination: inContainerInitPath,   // /sbin/docker-init INSIDE the container
    Type: "bind", Source: path, Options: []string{"bind", "ro"},
})

LookupInitPath() searches the libexec dirs and then $PATH, finds /usr/bin/docker-init, and bind-mounts it (the symlink is resolved by the mount) into the container, which then execs it as PID 1.

/usr/bin/docker-init is a symlink to /usr/bin/tini, a dynamic PIE, so the kernel must load /lib64/ld-linux-x86-64.so.2 from the container's rootfs. Alpine only ships /lib/ld-musl-x86_64.so.1. execve reports a missing ELF interpreter as ENOENT, which surfaces as "no such file or directory" for a file that is plainly present.

Reproduced on Photon OS 5.0 with docker-29.5.3-1.ph5 / tini-0.19.0-2.ph5:

# docker run --rm --init nginx:1-alpine true
exec /sbin/docker-init: no such file or directory

# docker run --rm --init debian:12 true            <- glibc image
(succeeds)

# docker run --rm -v /usr/bin/tini:/t:ro alpine:3 sh -c '/t --version'
sh: /t: not found                                   <- same ENOENT, no --init involved

# docker run --rm alpine:3 ls /lib64/ld-linux-x86-64.so.2
ls: /lib64/ld-linux-x86-64.so.2: No such file or directory

debian:12 succeeding is the control: a wrong host path would break every image, not only those without a glibc loader.

The regression comes from commit b3da2fa ("tini: Initial commit / Also seperate out tini from docker spec"), released as docker-27.3.1-5.ph5. Before it, docker.spec built tini itself and installed a statically linked binary:

make tini-static %{?_smp_mflags}
cp tini-static "$GOPATH/bin/docker-init"
install -p -m 755 bin/docker-init %{buildroot}%{_bindir}/docker-init

After it, docker-init is a symlink to the dynamically linked /usr/bin/tini, and SPECS/tini/tini.spec builds tini-static only to discard it with %exclude %{_bindir}/tini-static. master, dev and 4.0 are unaffected; they still build docker-init statically.

Upstream moby links docker-init statically on purpose: hack/dockerfile/install/tini.installer runs make tini-static, and the Dockerfile asserts it with xx-verify --static. Fedora does the same, shipping a tini-static subpackage that moby-engine depends on.

The same commit also dropped tini-disable-git.patch. tini's CMakeLists.txt overwrites tini_VERSION_GIT and git_version_check_ret via execute_process(), clobbering the -D values the spec passes. An RPM builds from a tarball with no .git, so the git call fails and the version suffix is silently dropped. moby parses docker-init --version expecting tini version X.Y.Z - git.COMMIT, so docker info reports an empty init version:.

Change

SPECS/tini/tini.spec (0.19.0-2 -> 0.19.0-3; not gated by subrelease, so it serves every subrelease)

• Package tini-static in a new subpackage instead of excluding it. The binary is already built and installed into the buildroot by %cmake_build / %cmake_install; the %exclude existed only to stop RPM's unpackaged-files check from failing the build.
• Restore tini-disable-git.patch as Patch0.

SPECS/docker/docker.spec (29.8.0-1 -> 29.8.0-2, subreleases 91 and later) and SPECS/90/docker/docker.spec (28.2.2-7.4.1 -> 28.2.2-7.4.2, subreleases 90 and earlier), identically:

• Point docker-init at tini-static.
• Add Requires: tini-static >= 0.19.0-3 to docker-engine, the subpackage that ships /usr/bin/docker-init. The version bound is deliberate: if docker-engine lands while an older tini without tini-static is installed, the dangling symlink gives the identical error message, so an unversioned dependency would leave that window open.

Requires: tini stays on the docker metapackage. docker is the only package requiring tini, so removing it would orphan /usr/bin/tini to tdnf autoremove; that is out of scope here.

Testing

• rpmspec -P (x86_64 and aarch64) and check_spec.py --mainline 93: SPECS/tini at subreleases 90 and 92, SPECS/docker at 92, SPECS/90/docker at 90: all pass.

🤖 Generated with Claude Code