client: close namespace file handle and defensively lazy unmount #25714
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.
Description
Nomad was holding open the namespace file handle, which would eventually get cleaned up by garbage collection. In batch jobs that ran very quickly, it was possible the leaked file handle was still open, and causing errors when attempting to unmount the namespace.
In addition to closing the file handle, we can use a
MNT_DETACHflag when unmounting to ensure that in the event a namespace file handle is left open, the namespace is still unmounted eventually and no resources are leaked.Fixes GH#25610
Testing & Reproduction steps
See GH#25610 for reproduction steps. In addition, you can see Nomad accessing the namespace file via shimming in an
exec.Command("fuser", -v, nsPath)right before unmounting. This can be reproduced in Podman and exec2.Links
Contributor Checklist
changelog entry using the
make clcommand.ensure regressions will be caught.
and job configuration, please update the Nomad website documentation to reflect this. Refer to
the website README for docs guidelines. Please also consider whether the
change requires notes within the upgrade guide.
Reviewer Checklist
backporting document.
in the majority of situations. The main exceptions are long-lived feature branches or merges where
history should be preserved.
within the public repository.