nerdctl exec hangs when it logs into stdout/stderr

[a14stoner]

Description

When nerdctl exec -it is called on a running container, and stdout is kept open from a command invoked inside that shell, the exec shell hangs until the command exits.

Basically its the same issue as this: https://github.com/moby/moby/issues/33039 This one is never solved. Maybe we can solve it here..

Steps to reproduce the issue

user@carlyle-linux ~ % nerdctl run -d --name test alpine sh -c 'while true; do sleep 10;done'
60b69398294b2a2490c07cc1e87fa63755e623d56f041817835b646544593e17
user@carlyle-linux ~ % nerdctl exec -it test sh
/ # touch /var/log/test
/ # tail -f /var/log/test &
/ # exit
<hangs>
^Z
^C
<still hangs>
# in another terminal: docker exec test killall tail
# now it exist
user@carlyle-linux ~ %

Describe the results you received and expected

Received: nerdctl exec closes stdout and tail exits when shell is exited Expected: nerdctl exec waits for tail to close stdout, which never happens

What version of nerdctl are you using?

Client: Version: v1.4.0 OS/Arch: linux/amd64 Git commit: 7e8114a82da342cdbec9a518c5c6a1cce58105e9 buildctl: Version: v0.11.6 GitCommit: 2951a28cd7085eb18979b1f710678623d94ed578

Server: containerd: Version: v1.7.1 GitCommit: 1677a17964311325ed1c31e2c0a3589ce6d5c30d

Are you using a variant of nerdctl? (e.g., Rancher Desktop)

Others

Host information

Client: Namespace: default Debug Mode: false

Server: Server Version: v1.7.1 Storage Driver: overlayfs Logging Driver: json-file Cgroup Driver: cgroupfs Cgroup Version: 1 Plugins: Log: fluentd journald json-file syslog Storage: native overlayfs Security Options: seccomp Profile: default Kernel Version: 4.18.0-348.23.1.el8_5.x86_64 Operating System: Red Hat Enterprise Linux 8.5 (Ootpa) OSType: linux Architecture: x86_64 CPUs: 16 Total Memory: 31.21GiB Name: xxxxxxxxx ID: 1d75a487-6ae2-42c3-982d-f9620fb5b567

WARNING: bridge-nf-call-iptables is disabled WARNING: bridge-nf-call-ip6tables is disabled

[apostasie]

@a14stoner I can't reproduce the problem (2.0.0-rc.1 / main).

Could you confirm on your side that this now works?

Thanks a lot.

[apostasie]

@AkihiroSuda OP is unresponsive. Since it is WFM on main, this may have been fixed by one of the patches on logging. Suggesting we close.