analyzer: add pre-container monitor to capture early file access by wswsmao · Pull Request #2129 · containerd/stargz-snapshotter (original) (raw)
I investigated this on nvcr.io/nvidia/tritonserver:25.07-py3 and found that during the pre-monitor phase fanotify can report the same file in two forms: with and without the target mount prefix. For example:
- Without prefix:
/usr/lib/x86_64-linux-gnu/libubsan.so.1.0.0/usr/lib/x86_64-linux-gnu/liblber.so.2.0.200/opt/hpcx/ompi/lib/libpmix.so.2.2.35
- With prefix:
/tmp/target296403442/usr/bin/nvidia-persistenced/tmp/target296403442/usr/lib/firmware/nvidia/535.261.03/gsp_ga10x.bin
After the container starts, these files are present in the container filesystem as expected:
# inside the running container
ls /usr/lib/x86_64-linux-gnu/libubsan.so.1.0.0 \
/usr/lib/x86_64-linux-gnu/liblber.so.2.0.200 \
/opt/hpcx/ompi/lib/libpmix.so.2.2.35
# outputs: all three paths exist
ls /usr/bin/nvidia-persistenced \
/usr/lib/firmware/nvidia/535.261.03/gsp_ga10x.bin
# outputs: both paths exist
So strings.HasPrefix(path, target) can legitimately be false for valid accesses under the rootfs. If we skip those, we will miss real file accesses.
The safer approach is to normalize: when the prefix is present, trim it; otherwise record the path as-is. Even if there is a non-existent file, recorder.Record will skip it here.