Left over fifo files(/run/containerd/fifo) are not getting cleared up when a container stops/exits using nerdctl

[brahmini7632]

Description

When a systemd service container stops, the fifo files under /run/containerd/fifo for the stopped/exited containers are not getting cleared up on a host, causing inode usage full.

And not seeing this behaviour when using nerdctl version v1.3.1 and containerd version v1.6.20 or v1.7.25

Steps to reproduce the issue

1. Start a container using nerdctl run and then stop and see if it's clears up the left over fifo file.

Describe the results you received and expected

When containers stops/exits using nerdctl, i would expect a fifo file associated with that containers will gets cleared up, doesn't have to clean it up manually.

What version of nerdctl are you using?

nerdctl: v1.7.6, but seeing the same issue even with latest versions.

Containerd: v1.7.18
Runc: v1.1.12
Flatcar: 3815.2.3
Kubernetes: 1.28.13
Calico: 3.28.0

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

None

Host information

Client:
Namespace: default
Debug Mode: false

Server:
Server Version: v1.7.25
Storage Driver: overlayfs
Logging Driver: json-file
Cgroup Driver: systemd
Cgroup Version: 2
Plugins:
Log: fluentd journald json-file syslog
Storage: native overlayfs
Security Options:
seccomp
Profile: default
cgroupns
Kernel Version: 6.6.74-flatcar
Operating System: Flatcar Container Linux by Kinvolk 4152.2.1 (Oklo)
OSType: linux
Architecture: x86_64

[apostasie]

Notes:

Removing explicitly does clean-up the fifos.

sudo find /var/run/ -type p -print
nerdctl run -ti --name foo debian echo foo
nerdctl rm -f foo
sudo find /var/run/ -type p -print

Self-removing containers do not.

sudo find /var/run/ -type p -print
nerdctl run --rm -ti --name foo debian echo foo
sudo find /var/run/ -type p -print

[apostasie]

@AkihiroSuda tag expert? It does not look like a trivial problem to fix.

[brahmini7632]

@apostasie so cleanup is not happening for the self removing containers. So, this is something needs to be fixed right ? Because this functionality was working before in v1.3.1, but not exactly sure in which version this was changed though. We started seeing this behavior from v1.7.6 and above.

[ningmingxiao]

/assign

[ningmingxiao]

#4406 will fix
because forget to call closer

[ningmingxiao]

can you try pr #4406 ？ @brahmini7632