Uh oh!
There was an error while loading. Please reload this page.
fix: hold startMx on the start path actually exercised - #14106
Merged
Conversation
startMx exists to serialize ContainerStart calls because the engine assigns published ports from ranges non-atomically. It is held by the plan executor's execStartContainer — a nearly dead code path (plans only emit OpStartContainer for paused/dead containers) — and NOT by startServiceContainer, the path every up/start actually runs. The protection is thus inoperative today: concurrent services publishing overlapping port ranges can race in the engine. Take the mutex around the real ContainerStart call and document the contract on the variable. Starts of different services were already serialized per-service (replicas start sequentially); this serializes the API call across services too, matching what the plan engine will do once the start phase converges (#14081). Part of #14074 (section C) / #14081 (lot 0). Signed-off-by: Nicolas De Loof <nicolas.deloof@gmail.com>
39 tasks
glours
approved these changes
Aug 20, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
startMxexists to serializeContainerStartbecause the engine assigns published ports from ranges non-atomically — but it is only held by the plan executor'sexecStartContainer, a nearly dead path (plans emitOpStartContaineronly for paused/dead containers).startServiceContainer, the path everyup/startactually runs, never takes it: the protection is inoperative today.This takes the mutex around the real
ContainerStartcall and documents the contract. Trade-off worth an explicit maintainer call (also raised in #14081): this serializes the start API call across services (replicas were already sequential). The alternative is deletingstartMxentirely — happy to flip this PR that way instead. Engine-side references to inform that call:startMxwas introduced by #12851 as a workaround for #12846 (duplicate host ports on random-port mappings); there is no dedicated moby issue, but moby/moby#50054 (merged, ships in Engine 28.3.0) explicitly fixes#12846 — a daemon port-allocator flaw (SO_REUSEADDRhid0.0.0.0vs specific-address clashes frombind()), introduced by the 28.0 port-mapping refactor (moby/moby#48567/#48132). Notably @robmry assessed on #12846 that the original problem was not a race between container starts, so the mutex likely never protected against that case; engines 28.0–28.2 remain exposed to it either way.Part of #14074 (section C) — lot 0 of #14081.
🤖 Generated with Claude Code