`nerdctl ps` is slow when there are containers whch have `Unknown` status

[haytok]

Description

When a container's shim process is stopped (e.g., via kill -STOP), nerdctl ps and nerdctl ps -a take approximately 4 seconds to return results.

$ time sudo nerdctl ps
CONTAINER ID    IMAGE    COMMAND    CREATED    STATUS    PORTS    NAMES

real	0m4.068s
user	0m0.007s
sys	0m0.017s

$ time sudo nerdctl ps -a
CONTAINER ID    IMAGE                              COMMAND        CREATED           STATUS     PORTS    NAMES
69e240372293    docker.io/library/alpine:latest    "sleep inf"    14 seconds ago    Unknown             hoge

real	0m4.033s
user	0m0.002s
sys	0m0.003s

Steps to reproduce the issue

ID=$(sudo nerdctl run -d --name hoge alpine sleep inf)
PID=$(ps aux | grep "containerd-shim.*$ID" | grep -v grep | awk '{print $2}')
sudo kill -STOP $PID
sudo nerdctl ps -a 

Describe the results you received and expected

Improve the display speed of the response when executing the nerdctl ps or nerdctl ps -a command where Unknown containers exist.

What version of nerdctl are you using?

latest

Details

$ sudo nerdctl version
Client:
 Version:       30bc9938.m
 OS/Arch:       linux/arm64
 Git commit:    30bc99387ff83cad68ea6f323560fd929b23fdb6.m
 buildctl:
  Version:      v0.18.0
  GitCommit:    95d190ef4f18b57c717eaad703b67cb2be781ebb

Server:
 containerd:
  Version:      89c7170db.m
  GitCommit:    89c7170db5d4f11868508001dda9ff18775705e1.m
 runc:
  Version:      1.2.2
  GitCommit:    v1.2.2-0-g7cb36325

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

Lima

Host information

Details

$ sudo nerdctl info
Client:
 Namespace:	default
 Debug Mode:	false

Server:
 Server Version: 89c7170db.m
 Storage Driver: overlayfs
 Logging Driver: json-file
 Cgroup Driver: systemd
 Cgroup Version: 2
 Plugins:
  Log:     fluentd journald json-file none syslog
  Storage: native overlayfs stargz
 Security Options:
  apparmor
  seccomp
   Profile: builtin
  cgroupns
 Kernel Version:   6.11.0-29-generic
 Operating System: Ubuntu 24.10
 OSType:           linux
 Architecture:     aarch64
 CPUs:             4
 Total Memory:     3.812GiB
 Name:             lima-haytok
 ID:               149f0072-b6bb-4d8a-97d8-e3b856af08c3

$ uname -ra
Linux lima-haytok 6.11.0-29-generic #29-Ubuntu SMP PREEMPT_DYNAMIC Fri Jun 13 20:32:41 UTC 2025 aarch64 aarch64 aarch64 GNU/Linux

[haytok]

My Investigation on nerdctl and containerd

This is because the ContainerStatus function in pkg/formatter/formatter.go makes two separate calls to containerd that both trigger the 2-second stateTimeout:

• c.Task(ctx, nil) at line 42
• task.Status(ctx) at line 54

Both calls eventually reach shimTask.State() in containerd's core/runtime/v2/shim.go, which communicates with the shim via ttrpc. When the shim is unresponsive, context deadline exceeded error occurs after the 2-seconds timeout (defined in getProcessState() at plugins/services/tasks/local.go).

Since each call (c.Task(ctx, nil) and task.Status(ctx)) times out independently, the total delay is approximately 4 seconds.

The root cause is thought to be that shimTask.State() does not properly handle the context deadline exceeded error. Currently, when a timeout occurs in ttrpc communication, the error is converted via errgrpc.ToNative(err), which does not preserve the deadline exceeded semantics.

As a result, the error is not properly propagated back to the client (e.g., nerdctl), and nerdctl cannot detect that the first call timed out to avoid making the redundant second API call.