If 2.17.10 left you unable to self-update, this one collects you. Nothing to do: your next update lands here, and the one after that puts your container back on the normal entrypoint.
Fixed
A container created by 2.17.10 could not self-update at all. It asks the next image for /sbin/tini, which 2.17.11 took back out, so the recreate failed on exec: "/sbin/tini": no such file or directory and rolled back — every time, forever. The rollback did its job and those installs kept running, but they could not move.
The image carries a small compatibility shim at that path now: with no arguments it starts Docksentry, which is exactly what the broken recreate is asking for.
And those containers then find their way back on their own. The fixed comparison still treated the pinned /sbin/tini as a deliberate override, so they would have carried it forever and never picked up a future init. The self-update now forgets that path when the target image does not ask for it — one ordinary update and the container is back to python3 /app/main.py, with nobody doing anything.
The failure message said what Docker said, which was no help. runc create failed: … no such file or directory is true and unusable. That one case now adds the line that matters: recreate the container once, your data is in the named volume.
Verified
Against the published 2.17.9 and 2.17.10 images with real named volumes, not stand-ins: eleven state files bit-identical, all ten settings read back, restart policy, label, environment and mounts unchanged, zero restarts — at both hops of 2.17.10 → shim → normal entrypoint.
Still open
The ssh process leak is still here — an install with an ssh:// host accumulates defunct processes, and restarting the container clears them. Fixing it by changing the entrypoint is what caused this whole sequence, so it will be fixed from inside the process instead. tcp://, context:// and single-host installs are not affected.