Open chris-raitano opened 1 year ago
We are able to run ruby by copying the binaries outside of C:\hpc, but can’t run it inside C:\hpc. (In other words, we can run it inside the container if the container copies the files onto the host filesystem, but we lose the benefits of filesystem isolation)
Since this works both in containerd 1.6 hpc and in containerd 1.7 outside of the c:\hpc directory, my guess is it's likely related to the new bind mount used for the C:\hpc directory.
Thanks for the really detailed and easy to repo steps. The current work around is to copy this to the host and run it.
This does appear to be due to the bind mount feature. It seems like something is executing from the host context which wouldn't see that binding: https://github.com/microsoft/hcsshim/blob/e7b0eab484b277ab1a30a282b7232744a34e6624/internal/jobcontainers/jobcontainer.go#L334-L341
Closing because workaround seems low effort and acceptable.
Closing because workaround seems low effort and acceptable.
@fady-azmy-msft ,
This workaround is not acceptable long term, only as a temporary measure to unblock us.
This is a serious bug that would impact any user trying to use HostProcess containers.
Is this being tracked somewhere else? If so, please provide a link to the issue so we can follow its resolution.
Closing because workaround seems low effort and acceptable.
@fady-azmy-msft I think that this bug may cause user's downtime if the user upgrade their cluster to use containerd 1.7 but hit this issue.
ACK. Engineering is looking into this issue, but I don't have any timelines on this
This issue has been open for 30 days with no updates. no assignees, please provide an update or close this issue.
This issue has been open for 30 days with no updates. no assignees, please provide an update or close this issue.
This issue has been open for 30 days with no updates. no assignees, please provide an update or close this issue.
Just FYI, in https://github.com/Azure/AKS/issues/3885, @AbelHu commented on this as "may not be fixed (by design)". (However, this might just mean "at this point".)
This issue has been open for 30 days with no updates. no assignees, please provide an update or close this issue.
This issue has been open for 30 days with no updates. no assignees, please provide an update or close this issue.
This issue has been open for 30 days with no updates. no assignees, please provide an update or close this issue.
This issue has been open for 30 days with no updates. no assignees, please provide an update or close this issue.
This issue has been open for 30 days with no updates. no assignees, please provide an update or close this issue.
This issue has been open for 30 days with no updates. no assignees, please provide an update or close this issue.
This issue has been open for 30 days with no updates. no assignees, please provide an update or close this issue.
This issue has been open for 30 days with no updates. @kiashok, please provide an update or close this issue.
This issue has been open for 30 days with no updates. @kiashok, please provide an update or close this issue.
Describe the bug My team runs a ruby script within a hpc (host process container). This works on containerd 1.6, but after upgrading to containerd 1.7 ruby fails to start with the below error message
The sxstrace.exe tool provides this additional info, which indicates that the manifest isn't found:
However, the manifest does exist at the expected location (C:\hpc\ruby31\bin\ruby_builtin_dlls\ruby_builtin_dlls.manifest) with the below content
We are able to run ruby by copying the binaries outside of C:\hpc, but can’t run it inside C:\hpc. (In other words, we can run it inside the container if the container copies the files onto the host filesystem, but we lose the benefits of filesystem isolation)
Since this works both in containerd 1.6 hpc and in containerd 1.7 outside of the c:\hpc directory, my guess is it's likely related to the new bind mount used for the C:\hpc directory.
To Reproduce I've created a lightweight container which we've been able to use to reproduce this
Dockerfile
main.ps1
And we've deployed it to our kubernetes cluster with this yaml, replacing
<IMAGE>
with the built container image from our container registryExpected behavior Expected behavior is to be able to run executables with side-by-side dlls inside a host process container. When running an exe within a container and a working directory inside the container filesystem (c:\hpc), we'd expect the SxS dll loader to be able to find manifests and load dlls within the container filesystem
Configuration:
Additional context