You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
refactor(envd): share one workload freezer across freeze paths
The live-upgrade handover added a second workload freeze/unfreeze path
(process.Service.FreezeWorkload/UnfreezeWorkload) that swept the user/pty
cgroups directly, independent of the HTTP API's existing /freeze, /unfreeze
and /init-deferred-thaw. Those API paths serialize their sweep through
API.freezeLock precisely so a pause freeze, a rollback unfreeze and the
resume thaw can't interleave and strand the workload frozen; the upgrade path
took no lock at all, so an upgrade freeze racing the resume thaw could leave
the sandbox frozen.
Extract the sweep and its lock into a single cgroups.WorkloadFreezer that
owns the manager plus a serializing semaphore and exposes Freeze/Unfreeze
(best-effort, joined errors; Unfreeze detaches from ctx cancellation so a
thaw always lands). main constructs one instance and passes it to both the
HTTP API and the process service, so every freeze/unfreeze caller now shares
the same lock. The canonical user/pty cgroup list moves to
cgroups.WorkloadProcessTypes.
The handover now holds that shared lock across the WHOLE window (freeze ->
serialize -> execve) via a new FreezeHold/FreezeWorkloadHold, not just the
freeze sweep, so a concurrent /init or /unfreeze thaw blocks on the lock until
the handover finishes and cannot thaw the workload mid-handover.
No behavior change to the existing endpoints: PostFreeze still returns 503 on
a cancelled request and 500 on a sweep failure, PostUnfreeze//init still
attempt every cgroup best-effort. Per-cgroup error logs collapse into one
joined log line per call.
Signed-off-by: Nikita Kalyazin <nikita.kalyazin@e2b.dev>
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
0 commit comments