runpod: a pid is not a process identity in a container (v0.2.99)
The root cause under the last three fixes. The pod registry recorded
os.getpid() and both readers skipped an entry whose pid matched ours as "our
own, the local pool handles it". Inside a container the engine comes up as the
SAME pid on every boot — 74, on the production host — so after a restart the
previous container's pod read as ours and was skipped by both
find_shared_pod (nothing to adopt) and sibling_is_provisioning (nothing
booting). The warm path then rented another A40 beside the one already running.
Three restarts this afternoon, three extra A40s, each billing until it was
terminated by hand.
Entries now carry a per-process nonce and identity is that. The pid is still
recorded, and an entry written before the nonce falls back to comparing it,
which is the old behaviour and no worse.
test_a_surviving_pods_token_is_remembered_across_a_restart simulated the new
process by monkeypatching os.getpid — the very thing that does not change. It
patches the nonce now, which is why it failed on this commit and passes on it.
Co-Authored-By:
Claude Opus 5 <noreply@anthropic.com>
Showing
Please
register
or
sign in
to comment