fix(envd): fall back to lazy unmount when forced NFS umount fails#2683
Conversation
The current setupNFS path on resume runs `umount --force` against the inherited NFS mount. For NFS, MNT_FORCE only aborts in-flight RPCs (fs/nfs/super.c::nfs_umount_begin); it does not detach the mount when the customer's resumed processes still hold open FDs into it. With the NFS proxy reachable on the same node there are no in-flight RPCs to abort, so the call fails with EBUSY and the orchestrator surfaces "failed to setup NFS volumes: failed to unmount stale NFS mount" as HTTP 400 to the customer. Now: try `umount --force` first (unchanged fast path), and on any failure fall back to `umount --lazy` (MNT_DETACH) before bubbling the error. Lazy detach unlinks the mount from the namespace immediately, the path becomes available for the fresh mount, and the kernel cleans up when the surviving FDs close. Old FDs keep reading from the previous mount — correct when the NFS source IP is unchanged across resume, and produces the same ESTALE outcome the customer would have seen from a successful forced unmount when the source changed. When the fallback triggers we log a warning so the rate is observable.
PR SummaryMedium Risk Overview Reviewed by Cursor Bugbot for commit ff2c941. Bugbot is set up for automated code reviews on this repo. Configure here. |
❌ 7 Tests Failed:
View the full list of 13 ❄️ flaky test(s)
To view more test analytics, go to the Test Analytics Dashboard |
There was a problem hiding this comment.
Code Review
The fallback to umount --lazy will not execute if the initial umount --force fails due to a context timeout because both commands share the same context. To ensure the mount is detached when the first command hangs, the fallback should be attempted with a fresh context or a separate timeout.
|
Superseded by #2700 (move envd into a dedicated network namespace), which addresses the root cause. |
There was a problem hiding this comment.
LGTM, small defensive fallback for NFS unmount with the gemini-suggested fresh context fix already applied.
Extended reasoning...
Overview
Small two-file change in packages/envd: unmountNFS now falls back to umount --lazy when umount --force fails (customer FDs holding the mount), and the envd version is bumped to 0.5.24. Total logic change is ~7 lines.
Security risks
None. This is an internal-to-envd unmount fallback running on resume. No new inputs, no privilege changes, no exposure surface.
Level of scrutiny
Low. The change is mechanical, self-contained, and only adds a fallback on an existing error path. The prior failure mode was a hard error; the new behavior tries one more thing before returning the same error. The fresh-context concern raised by gemini-code-assist was already addressed (commit 36f8f9d) using context.WithoutCancel with a 2s timeout, so the lazy attempt isn't starved by the parent budget.
Other factors
Bug hunting system found no bugs. Codecov failures are all pre-existing flakes (>50% flake rate in main). No outstanding reviewer comments. Author noted this is bifrost-track and will be superseded by #2700, but the fix is still useful in the interim.
Falls back to
umount --lazywhen forced unmount on resume fails with EBUSY (customer FDs hold the mount).