-
Notifications
You must be signed in to change notification settings - Fork 258
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Retain pause.exe as entrypoint for default pause images #1615
Conversation
738afec
to
df289c7
Compare
This PR addresses #1576 and is related to containerd/containerd#7752 |
df289c7
to
1327193
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Minor comments, but LGTM otherwise!
f9b6b73
to
5c142d6
Compare
Signed-off-by: Kirtana Ashok <[email protected]>
5c142d6
to
72e0f77
Compare
As suggested by @kevpar, I have also updated the github bug and discussion item opened for this to explicitly call out the fix. |
CI / integration-tests (windows-2019) is failing with an unrelated error "2023-01-24T23:12:15.7814225Z === CONT TestCRIImagePullTimeout |
Signed-off-by: Kirtana Ashok <[email protected]> Signed-off-by: Kirtana Ashok <[email protected]> Co-authored-by: Kirtana Ashok <[email protected]> (cherry picked from commit 6cd5572) Signed-off-by: Kirtana Ashok <[email protected]>
(cherry picked from commit 6cd5572) Signed-off-by: Kirtana Ashok <[email protected]> Co-authored-by: Kirtana Ashok <[email protected]>
@katiewasnothere - I know this is old news, but can we just have MS provide "halt.exe" in the root nanoserver+ compatibility sets. I feel like we have been talking about this for ages and ages lol. Here is what I want to do: docker (or containerd) run --detach nanoserver halt I dont want stdin/stdout to cause the reader to block. I just want a halted process that never exits until sent sigterm/kill (ctrl+c or exit) and then exits. This should be inside the containers by default IMO, and it cant take more than a few kb of space being such a small program. Can we forward on to Windows PM to see if this can be done? We shouldnt need ping to hold a container alive.. :). Ty!! |
Hey @jterry75 what would the benefit of this be over pause.exe? If you're trying to hold a container alive this can be done from cmd or at the application level, but I don't see the benefit of holding an empty container idle? Maybe I'm missing context here. |
Its possible we are way out of the loop, but pause.exe requires that the stdin pipe be valid. Meaning you cannot run a detached instance for the process to stay alive. The reason why the pause container runs Kubernetes has to distribute a custom "pause" container to do just this. They wrote a pause.exe process themselves that does the hanging here because Windows does not have an in-built way to do that. There is no reason this should not be part of the base image IMO |
Currently, the entrypoint for all pause containers is being overriden to ping.exe immaterial of the pause image used. This is causing perf issues even when the default pause image is used.
This PR retains /pause.exe as entrypoint for the default pause image and overrides to ping.exe only if the default arg/commandline of the non-default pause image being used is "c:\windows\system32\cmd.exe" . We intend to completely get rid of the ping override by containerd/1.7 and hence throw a warning log message to switch to the default pause image asap.