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

[dcasota]

Part of #1605. This is the 6.0 counterpart of #1661 (5.0); the defect and the change are identical.

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.

Why it fails

/usr/bin/docker-init is 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.

The failure was reproduced on Photon 5.0 (docker-29.5.3-1.ph5 / tini-0.19.0-2.ph5). 6.0 carries the identical packaging — ln -srv %{buildroot}%{_bindir}/tini %{buildroot}%{_bindir}/docker-init plus a tini.spec that excludes tini-static — so it has the same defect:

# 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.

Where it regressed

Commit b3da2fa ("tini: Initial commit / Also seperate out tini from docker spec"), which landed on both 5.0 and 6.0. 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 became a symlink to the dynamically linked /usr/bin/tini, and the new SPECS/tini/tini.spec builds tini-static only to discard it with %exclude %{_bindir}/tini-static.

master/dev/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.

Changes

SPECS/tini/tini.spec (0.19.0-1 → 0.19.0-2)

• 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, also dropped by b3da2fa. 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 currently reports an empty init version:.

SPECS/docker/docker.spec (28.2.2-3 → 28.2.2-4)

• Point docker-init at tini-static.
• Add Requires: tini-static >= 0.19.0-2 to docker-engine, the subpackage that actually ships /usr/bin/docker-init.

The version bound is deliberate. I simulated an upgrade in which docker-engine lands while an older tini without tini-static is installed: the dangling symlink reproduces the identical error message, so an unversioned dependency would leave that window open.

Requires: tini stays on the docker metapackage. docker is currently the only package requiring tini, so removing it would orphan /usr/bin/tini to tdnf autoremove — out of scope for this fix.

Verification

The packages were built and tested from the 5.0 branch, where the change is line-for-line the same apart from the release numbers:

rpm -qlp tini-0.19.0-3.rpm         -> /usr/bin/tini
rpm -qlp tini-static-0.19.0-3.rpm  -> /usr/bin/tini-static
file /usr/bin/tini-static          -> ELF 64-bit LSB executable, statically linked
readelf -l /usr/bin/tini-static    -> 0 INTERP segments
/usr/bin/tini-static --version     -> tini version 0.19.0 - git.de40ad0

With docker-init symlinked to tini-static exactly as the spec creates it:

# docker run --rm --init nginx:1-alpine true
(succeeds)
# docker run --rm --init nginx:1-alpine ps -o pid,comm
PID   COMMAND
    1 docker-init

Note on scope of testing: the RPM build was done locally, not through the Photon build system, and the 6.0 packages themselves were not built — a builder run on this branch is worth doing before merge.