feat: add --no-stdin flag to container attach

[subashkotha]

Summary

This PR adds support for a new flag in the nerdctl container attach command:

--no-stdin: disables attaching stdin to the container

Notes

We are not adding --sig-proxy in this PR due to a limitation in nerdctl: attach only works for containers started with -it ref - #2108
When -it is used, signals like Ctrl+C (SIGINT) are sent directly to the container process by the TTY, bypassing nerdctl.
As a result, --sig-proxy=false has no effect in such cases and cannot be used/tested reliably under current constraints.

Testing

• Added an integration test to validate that input is not sent to the container when --no-stdin is used.
• Verified behavior across re-attached containers.

[AkihiroSuda]

Needs -e ?

[subashkotha]

We're using detach-keys here specifically to immediately detachment after attach. hence there is no need for passing in env variables.

[AkihiroSuda]

Please squash the commits

[Shubhranshu153]

Flaky Test PR's:
#4196
#4198
#4199

[subashkotha]

Hi @apostasie , @AkihiroSuda

I have updated the PR addressing comments, can you please take a look.

[apostasie]

Thanks a lot @subashkotha

Issues on the CI are AFAIK:

• rekor down
• gomodjail (tentative fix in [CI]: workaround gomodjail concurrency issue #4198)
• windows slow (tentative fix in [CI]: small fixes #4199 )

I am bit concerned about rootless old getting to timeout at 45 mins+ (clearly getting stuck in container tests).

Suggestion would be that we first merge a raft of fixes for the CI (pending), and then you could rebase on top of main to get a cleaner run.

Does that work for you?

[subashkotha]

Sure, @apostasie
I'll rebase after fixes for CI are merged. Can you approve the PR if there are no concerns, thanks!

[apostasie]

@subashkotha thanks.
Code looks good to me, so, approved, but I would like to see a clean CI run with no timeout before we merge.
Also note that I am not a maintainer: approval from me is just advisory, and you will need a maintainer approval for merge.

[AkihiroSuda]

Could you try rebasing?

[apostasie]

This does not feel right. EL8 does not get past the new test.

[apostasie]

Does the loop serve a purpose here?

If I am reading this correctly, we attach to the container, and we will not return until the sleep 5 has lapsed.
Once it has elapsed, we are guaranteed to have "ready" in the log, right?

[subashkotha]

Yes, I tried removing the loop, but the test failed because it couldn't reliably assert "ready" in the logs (example failure). The loop ensures we wait until the container is actually ready before feeding input — without it, the test becomes racy.

[apostasie]

Thanks for keeping up with this @subashkotha
Appreciated.

Docker Hub is now flipping a 429 on us (<- this is rate limiting from Docker Hub) - unfortunately there is nothing to do about that but wait for it to chill (@AkihiroSuda so tired of this - need to act)

Let's give it a minute then we will re-run.

[AkihiroSuda]

Could you rebase to see if passes the CI?

[AkihiroSuda]

Seems hanging up on almalinux-8 (cgroup v1)

[apostasie]

Seems hanging up on almalinux-8 (cgroup v1)

Reading tea-leaves: we get stuck in the Feed loop waiting for the logs to show ready (which never happens for whatever reason <- this is the culprit).

While tigron does drop the main command after 3 minutes, we might still be waiting (too politely) on the ioGroup (which is dead looping):
https://github.com/containerd/nerdctl/blob/main/mod/tigron/internal/com/command.go#L327

Maybe I could add a reasonable timeout of the ioGroup Wait to deal with these conditions.

@subashkotha so, beside the problem in tigron ^ that prevents this from timeouting (I will deal with that), could you add a counter in your loop waiting for ready so that we stop iterating after - let's say - 500 iterations (or 50 iterations if you increase the sleep to 1 second, which I would recommend to reduce pressure on the runtime).

UPDATE: Tigron issue tracked in #4231

[apostasie]

Latest push:

• two counts of CNIEnv concurrency issues #3556
• some unrelated failure with TestDiff being racy (tentative fix in [CI]: fix flaky diff test #4232)

Confirmed that on EL8, you never see ready no matter how long you wait.
Maybe this is a logs bug.
Reading this again.

[apostasie]

@fahedouch
Here is the scenario:

nerdctl run -ti --name foo image "sh" "-c" `echo ready; sleep 5`

Then detach (ctrl+p ctrl+q).

Then we nerdctl logs foo, but in some cases we never see ready in the logs after an extended period of time.

Do you have an intuition on this? Could it be a bug in logging with detach?

[apostasie]

@subashkotha let's test my hypothesis that there is a bug in logging.

So, instead of sending cmd.Feed(bytes.NewReader([]byte{16, 17})) after one second, instead do your logs / wait on ready BEFORE sending the escape sequence.

eg:

cmd.Feeder(func()io.Reader{

for {
				out := helpers.Capture("logs", data.Identifier())
				if strings.Contains(out, "ready") {
					break
				}
}

return bytes.NewReader([]byte{16, 17})

}
)

[apostasie]

Pseudo-code ^ just add back the sleep and make this proper - thanks a lot! :-)

[subashkotha]

Thanks, let me try this out.

[apostasie]

Looks indeed like a log bug: #4233

@subashkotha suggested change above should allow you to work-around it.