I replaced containerd-shim with this rust version, but it's not working, and just disconnected without any error, could you please help how to look into this? Thanks!

Jan 12 01:25:10 blade-5 containerd[1038855]: time="2023-01-12T01:25:10.167197484Z" level=info msg="CreateContainer within sandbox \"f1d615c78e3365992fa92ad36b24b05fb9e471688358dc2add58712ba22bf6db\" for &ContainerMetadata{Name:alpine,Attempt:5,} returns container id \"557e3eb3129cea488bebe475d1f0734145c213e0e4c248dd613e630b8ea9df8d\""
Jan 12 01:25:10 blade-5 containerd[1038855]: time="2023-01-12T01:25:10.168317205Z" level=info msg="StartContainer for \"557e3eb3129cea488bebe475d1f0734145c213e0e4c248dd613e630b8ea9df8d\""
Jan 12 01:25:10 blade-5 containerd[1038855]: [INFO] Create request for CreateTaskRequest { id: "557e3eb3129cea488bebe475d1f0734145c213e0e4c248dd613e630b8ea9df8d", bundle: "/run/containerd/io.containerd.runtime.v2.task/k8s.io/557e3eb3129cea488bebe475d1f0734145c213e0e4c248dd613e630b8ea9df8d", rootfs: [Mount { type_: "overlay", source: "overlay", target: "", options: ["index=off", "workdir=/data0/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/18826/work", "upperdir=/data0/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/18826/fs", "lowerdir=/data0/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/28/fs:/data0/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/27/fs:/data0/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/26/fs:/data0/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/25/fs"], special_fields: SpecialFields { unknown_fields: UnknownFields { fields: None }, cached_size: CachedSize { size: 0 } } }], terminal: false, stdin: "", stdout: "/run/containerd/io.containerd.grpc.v1.cri/containers/557e3eb3129cea488bebe475d1f0734145c213e0e4c248dd613e630b8ea9df8d/io/3215463519/557e3eb3129cea488bebe475d1f0734145c213e0e4c248dd613e630b8ea9df8d-stdout", stderr: "/run/containerd/io.containerd.grpc.v1.cri/containers/557e3eb3129cea488bebe475d1f0734145c213e0e4c248dd613e630b8ea9df8d/io/3215463519/557e3eb3129cea488bebe475d1f0734145c213e0e4c248dd613e630b8ea9df8d-stderr", checkpoint: "", parent_checkpoint: "", options: MessageField(Some(Any { type_url: "runtimeoptions.v1.Options", value: [], special_fields: SpecialFields { unknown_fields: UnknownFields { fields: None }, cached_size: CachedSize { size: 0 } } })), special_fields: SpecialFields { unknown_fields: UnknownFields { fields: None }, cached_size: CachedSize { size: 0 } } }
Jan 12 01:25:10 blade-5 containerd[1038855]: [INFO] Create request for 557e3eb3129cea488bebe475d1f0734145c213e0e4c248dd613e630b8ea9df8d returns pid 1040500
Jan 12 01:25:10 blade-5 containerd[1038855]: [INFO] Connect request for ConnectRequest { id: "557e3eb3129cea488bebe475d1f0734145c213e0e4c248dd613e630b8ea9df8d", special_fields: SpecialFields { unknown_fields: UnknownFields { fields: None }, cached_size: CachedSize { size: 0 } } }
Jan 12 01:25:10 blade-5 containerd[1038855]: time="2023-01-12T01:25:10.527656970Z" level=info msg="shim disconnected" id=557e3eb3129cea488bebe475d1f0734145c213e0e4c248dd613e630b8ea9df8d
Jan 12 01:25:10 blade-5 containerd[1038855]: time="2023-01-12T01:25:10.527745732Z" level=warning msg="cleaning up after shim disconnected" id=557e3eb3129cea488bebe475d1f0734145c213e0e4c248dd613e630b8ea9df8d namespace=k8s.io
Jan 12 01:25:10 blade-5 containerd[1038855]: time="2023-01-12T01:25:10.527765055Z" level=info msg="cleaning up dead shim"
Jan 12 01:25:10 blade-5 containerd[1038855]: time="2023-01-12T01:25:10.527754174Z" level=error msg="failed to get task exit status for \"f1d615c78e3365992fa92ad36b24b05fb9e471688358dc2add58712ba22bf6db\"" error="ttrpc: closed: unknown"
Jan 12 01:25:10 blade-5 containerd[1038855]: time="2023-01-12T01:25:10.527726014Z" level=error msg="Failed to pipe stdout of container \"557e3eb3129cea488bebe475d1f0734145c213e0e4c248dd613e630b8ea9df8d\"" error="read /proc/self/fd/45: file already closed"
Jan 12 01:25:10 blade-5 containerd[1038855]: time="2023-01-12T01:25:10.527654842Z" level=info msg="shim disconnected" id=f1d615c78e3365992fa92ad36b24b05fb9e471688358dc2add58712ba22bf6db
Jan 12 01:25:10 blade-5 containerd[1038855]: time="2023-01-12T01:25:10.527871643Z" level=error msg="Failed to pipe stderr of container \"557e3eb3129cea488bebe475d1f0734145c213e0e4c248dd613e630b8ea9df8d\"" error="read /proc/self/fd/46: file already closed"
Jan 12 01:25:10 blade-5 containerd[1038855]: time="2023-01-12T01:25:10.527900006Z" level=warning msg="cleaning up after shim disconnected" id=f1d615c78e3365992fa92ad36b24b05fb9e471688358dc2add58712ba22bf6db namespace=k8s.io

Containerd version:1.6.14
config change:

runtime_type = "io.containerd.runc.v2-rs"

          is there any concern about resolving symlinks or relative paths via canonicalize here?

Originally posted by @jsturtevant in #254 (comment)

The published crate containeird-client-0.1.2 is missing the with_namespace macro.

Would it be possible to publish a newer version containing the macro?

Containerd is still evolving quickly, interfaces and behaviors may change between Cotnainerd versions. It would be great to document compatible Containerd versions for each version of rust crates in the README.md.

We found that cpu usage of containerd-shim-runc-v2-rs process was overheaded even though no task requests called from containerd.

I find this issus from
https://github.com/containerd/containerd/issues/9568

The community shim links child procress through copyIO. The shim and containerd have separate pipe links, so the shim can close the pipe when the exec process exit. r-shim use the FIFO-IO directly.

let channel = connect("/run/containerd/containerd.sock").await;
let channel = match channel {
Ok(channel) => channel,
Err(error) => panic!("Problem connecting to containerd: {:?}", error),
};

This code is getting the error below

thread 'main' panicked at 'Problem connecting to containerd: tonic::transport::Error(Transport, hyper::Error(Connect, Os { code: 13, kind: PermissionDenied, message: "Permission denied" }))', src/./containers/containerd/containerd.rs:50:27

How should I go about fixing it? Did I set up containerd wrong?

I used the following command to set up containerd and start it. Please advise. Thanks!

sudo tar Cxzvf /usr/local containerd-1.6.6-linux-arm64.tar.gz

# start containerd
systemctl daemon-reload
systemctl enable --now containerd

Seems there's a confusion/misuse of "runtime id/runtime class" and "container id" in shim/lib.rs.
We need to refine the Shim::new() to take both the "runtime class id" and the "container id".

Allow for using the client create on Windows (https://github.com/containerd/rust-extensions/tree/main/crates/client). Currently it fails to build with:

error[E0432]: unresolved import `tokio::net::UnixStream`
  --> C:\Users\jstur\.cargo\registry\src\index.crates.io-6f17d22bba15001f\containerd-client-0.4.0\src\lib.rs:81:9
   |
81 |     use tokio::net::UnixStream;
   |         ^^^^^^^^^^^^^^^^^^^^^^ no `UnixStream` in `net`
   |
note: found an item that was configured out
  --> C:\Users\jstur\.cargo\registry\src\index.crates.io-6f17d22bba15001f\tokio-1.32.0\src\net\mod.rs:51:27
   |
51 |     pub use unix::stream::UnixStream;
   |                           ^^^^^^^^^^

For more information about this error, try `rustc --explain E0432`.
error: could not compile `containerd-client` (lib) due to previous error
make: *** [Makefile:32: build-wasm] Error 101

For shim of golang version, containerd can receive an event of OOMKilled when a container is oom killed. the reason of container exit is set to "OOMKilled". kubernetes can also get this reason the show it to user. This is a useful information somtimes, because otherwise users don't know why their container exit, and can not find any clues.

We should replace"unsafe" functions with std or 3rd prty library although we know it's quite safe in fact. For reasons:

1. Simplify code, making it clear
2. Maintained by other contributors, reducing our burden

It would be nice to have a --version arg for the shims to be able to determine the build version information.

Currently, async for rust is gradually used, so it is necessary to support both async and async for containerd-shim-protos.

We have found a bug that pods restarted after containerd restarted, especially on the condition that the container IO is very frequent. The parent process of the container processm that is our async containerd
-shim process is not very careful to handle the pipe of container process IO. Thus when containerd restarts, some of containers, especially that has huge IO requests, would receive EPIPE and exited unexpectly.

The shim-client provides message and trait definitions for both server and client, so it would be great to rename it as shim-proto.

tried to run the shim as below.

sudo ctr run --rm --runtime io.containerd.runc.v2-rs -t docker.io/library/hello-world:latest hello

And got failure as below.

unix:///run/containerd/e2575a053069a275.sock: connect: invalid argument: unknown

I tried to debug and found that ctr seem failed to connect address the shim created

In Rust, synchronous (sync) code is blocking, which means it will wait for a response before continuing with the next task. This can lead to slow performance if there are many synchronous operations.

On the other hand, asynchronous (async) code is non-blocking, which means it can perform other tasks while waiting for a response. This allows for better performance and can be especially useful in network applications where there are many concurrent requests.

Initially, I was hesitant about using async shim because it wasn't very stable in testing. Additionally, the Rust async ecosystem is still evolving and some libraries may not have full support for async yet. However, after doing some research, I found that most mainstream rust crates are now using async crates. If there are any bugs in async shim, we should work on fixing them instead of relying on sync code.

Therefore, I decide to stop developing sync code. If you have any opinion, please leave a comment below. If there are no objections after one month(May 15th), we'll proceed with the plan to remove sync code in the next version.

Before we officially deprecate it, I will still commit PRs to fix some bugs.

/cc @mxpv @jiangliu @abel-von @ytoml @wedsonaf @AkihiroSuda

It would be nice if fetching content was supported to be able to pull images via the client https://github.com/containerd/containerd/blob/main/cmd/ctr/commands/content/fetch.go without unpacking

The equivalent of ctr content fetch <img> ...

Hi, there.

I encountered an issue with the protobuf dependency. The details are as follows:

• Kata Containers' runtime-rs has a dependency on protobuf v3.2.0 and ttrpc v0.7.1.
• Kata Containers has a dependency on containerd-shim-protos v0.3.0, which correctly depends on protobuf v3.2.0 and ttrpc v0.7.1.
• Kata Containers also has a dependency on containerd-shim v0.3.0. However, it has a dependency on containerd-shim-protos v0.2.0, which in turn depends on protobuf v2.28 and ttrpc v0.6. See containerd-shim v0.3.0 and containerd-shim-protos v0.2.0.

A feasible solution is to release a new version of containerd_shim with the correct dependency:

• containerd-shim-protos v0.3.0
• protobuf v3.2.0
• ttrpc v0.7.1

Wdyt? /cc @mxpv @fuweid @jiangliu

Seems currently implementation supports UNIX-like OSs only, is there any plan for Windows or it's ok to focus on Unix-like OSs?

          > @jsturtevant any thoughts on

---- synchronous::publisher::tests::test_connect stdout ----
thread 'synchronous::publisher::tests::test_connect' panicked at 'called `Result::unwrap()` on an `Err` value: Ttrpc(Windows(231))', crates\shim\src\synchronous\publisher.rs:159:50
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

231 is all pipe instances are busy might be a flaky test. Has is shown up in other PR's? I will create an issue and see if I can reproduce.

Originally posted by @jsturtevant in #152 (comment)

👋 Hi, team. Thanks for your effort on this project. I love and use this project.

Problem

There are two failed cases on the CI.

• TestTaskUpdate

  === CONT  TestTaskUpdate
      container_linux_test.go:249: Others("Other: set mem limit: unable to write to a control group file caused by: Os { code: 13, kind: PermissionDenied, message: \"Permission denied\" }"): unknown
      container_linux_test.go:258: expected memory limit to be set to 67108864 but received 33554432
  --- FAIL: TestTaskUpdate (0.14s)
  

• TestContainerMetrics

  === CONT  TestContainerMetrics
  1160
      container_test.go:1345: not found
  1161
  --- FAIL: TestContainerMetrics (0.23s)
  

Expected behavior

Pass the CI

How to solve

Should we ignore these test cases once?

There's an ongoing efforts to upstream Alibaba's runD for Kata 3.0. There's a similar implementation of shim-client/shim-proto from runD. It would be great to consolidate these two implementations.

There was a report that we saw a speed up in runwasi after turning logging off. #247 makes logging configurable but we should investigate the report:

        I _suspect_ that the performance issues have more to do with mutex contention in `FifoLogger`, but I haven't done any analysis to confirm.

Originally posted by @lann in #247 (comment)

There are duplicating modules mount.rs in shim-protos crate.

• shim-protos/src/shim/mount.rs
• shim-protos/src/events/mount.rs
  They are both generated from github.com/containerd/containerd/api/types/mount.proto.
  Thus, we have to write redundant conversion like this.

Is it possible to combine these two mount.rs into single module ?

After we do crictl exec -ti $container_id bash and exit, and then crictl rmp -f $podid, the shim process do not exit. this is because the spawned io copy task will make a blocking stdin read task in the tokio runtime, when main exit, it will call drop of tokio runtime, which will wait for the exit of that task, then blocking main thread exit.

and there is another bug, when we kill <pid of shim> when container is running, the shim will not exit, which is expected, but the subsequent exec can not exit, that is because the signal handler thread exit when SIGTERM received, for the subsequent signals, including SIGCHLD has no one to handle them.

Follow up to #190. In order to ugprade ttrpc crate to 0.8.1 and up, we need to make some change changes to support cancel_rx in ttrpc context.

2023-09-27T16:54:46.0829155Z === CONT  TestContainerAttachProcess
2023-09-27T16:54:46.2301858Z     container_linux_test.go:716: write /proc/self/fd/29: broken pipe
2023-09-27T16:54:46.2314358Z     container_linux_test.go:724: write /proc/self/fd/29: broken pipe
2023-09-27T16:54:46.2384256Z     container_linux_test.go:746: expected output "hello\nhello\n" but received ""
2023-09-27T16:54:46.2591524Z --- FAIL: TestContainerAttachProcess (0.18s)
2023-09-27T16:54:46.2592190Z === CONT  TestContainerAttach
2023-09-27T16:54:46.3625257Z     container_linux_test.go:515: write /proc/self/fd/29: broken pipe
2023-09-27T16:54:46.3637557Z     container_linux_test.go:528: write /proc/self/fd/29: broken pipe
2023-09-27T16:54:46.3876891Z     container_linux_test.go:549: expected output "hello\nhello\n" but received ""
2023-09-27T16:54:46.3910662Z --- FAIL: TestContainerAttach (0.13s)

Occurrences:
https://github.com/containerd/rust-extensions/actions/runs/6328911110/job/17188102327?pr=206
#181 (comment)

https://github.com/containerd/rust-extensions/blob/main/crates/shim/src/cgroup.rs#L195
cgroup-rs

Hello, I'm trying to use the grpc bindings from containerd-client.

And when I try to list containers in the namespace moby (I also tried with other namespaces I've created), I get an error about the namespace missing.

Here is a sample of my code:

#[tokio::main]
async fn main() -> anyhow::Result<()> {
    tracing_subscriber::fmt().with_max_level(Level::INFO).init();

    let channel = containerd_client::connect("/run/containerd/containerd.sock").await?;

    let mut tasks_client = ContainersClient::new(channel.clone());

    let req = ListContainersRequest::default();
    let req = with_namespace!(req, "moby");
    info!("{:?}", req);

    let container_list = tasks_client.list(req.into_inner()).await?;
    info!("{:?}", container_list.into_inner());

    Ok(())
}

Here is the tonic Request sended to containerd:

Request { metadata: MetadataMap { headers: {"containerd-namespace": "moby"} }, message: ListContainersRequest { filters: [] }, extensions: Extensions }

I have this error:

Error: status: FailedPrecondition, message: "namespace is required: failed precondition", details: [], metadata: MetadataMap { headers: {"content-type": "application/grpc"} }

Versions

Here is my version of containerd (at least I can get this information from containerd):
VersionResponse { version: "1.6.21", revision: "3dce8eb055cbb6872793272b4f20ed16117344f8" }

[dependencies]
anyhow = "1.0.72"
containerd-client = "0.3.0"
prost = "0.11.9"
prost-types = "0.11.9"
tokio = { version = "1.29.1", features = ["full"] }
tonic = "0.9.2"
tracing = "0.1.37"
tracing-subscriber = "0.3.17"

[build-dependencies]
tonic-build = "0.9.2"

Maybe I did something wrong somewhere, but I can't see where.
Hoping you could enlighten me.

          Frankly speaking (in longer term) I think we should not carry cgroups related code in the `shim` crate. shim crate supposed to be the foundation for building new shim runtimes for containers on all platforms, without carrying any implementation details.

Originally posted by @mxpv in #254 (comment)

Hi there,

I am a maintainer from runwasi project under the Containerd org. runwasi is taking a dependency on the containerd-shimcrate. I'd like to request for a new release of this crate because it's been a year since the last release and we want to include features like #150 in the new release of runwasi's containerd-shim-wasm crate. 🙏🙏

Description

I have a WebAssembly-based container runtime daemon in local host. It can handle all containers' creation, running, deletion.

Now I want to integrate it with containerd and k8s to support distributed runtime. I think I should implement a shim to transfer the instruction between the containerd and my runtime. Maybe use grpc for communication of shim and runtime...?

Then I wonder which lib of this repo should I choose to construct the shim. this crate?

Go shim uses memory.oom_control and cgroup.event_control to register and report OOM (Out of Memory) events in the cgroup. Do you now have any plans for this aspect in Rust shim?

Follow up for #110
There are a couple of integration tests that we disabled on CI (#104) which require investigation:

• TestContainerPTY
• TestContainerExecLargeOutputWithTTY
• TestTaskUpdate
• TestTaskResize

We should fix the shim and enable them back.

I want to try runc crate to run example code：

use runc;

#[tokio::main]
async fn main() {
    let config = runc::Config::new()
        .root("./new_root")
        .debug(false)
        .log("/path/to/logfile.json")
        .log_format(runc::LogFormat::Json)
        .rootless(true);

    let client = config.build_async().unwrap();

    let opts = runc::options::CreateOpts::new()
        .pid_file("/path/to/pid/file")
        .no_pivot(true);
    
    client.create("container-id", "path/to/bundle", Some(&opts)).unwrap();
}

[dependencies]
tokio = { version = "1.29.1", features = ["full"] }
runc = { git = "https://github.com/containerd/rust-extensions", features=["async"] }

But I ran into an error：

I first tried to build the project:

root@ecsHyNL:~/dierbei/rust-extensions# cargo build --example skeleton

Tried to run the program after that, but it failed.

root@ecsHyNL:~/dierbei/rust-extensions# ctr run --rm --runtime ./target/debug/examples/skeleton docker.io/library/hello-world:latest hello
ctr: failed to start shim: start failed: : exec: "/": permission denied: unknown

Containerd version:

root@ecsHyNL:~/dierbei/rust-extensions# containerd -v 
containerd github.com/containerd/containerd v1.7.2 0cae528dd6cb557f7201036e9f43420650207b58

OS:

root@ecsHyNL:~/dierbei/rust-extensions# uname -a 
Linux ecsHyNL 5.15.0-79-generic #86-Ubuntu SMP Mon Jul 10 16:07:21 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

All operations are performed under the root user.

I tried to run the shim as below.

sudo ctr run --rm --runtime io.containerd.skeleton.v1 -t docker.io/library/hello-world:latest hello --debug

And got failure as below.

ctr: failed to create shim: /containerd.task.v2.Task/Create is not supported: not found

I tried to debug it but don't know the log location. Can you please share log location?

The stdout/stderr of runc command is deliverd by a "pipe" by default here:
https://github.com/pwFoo/rust-runc/blob/master/src/lib.rs#L509

        let process = Command::new(&self.command)
            .args(&args.clone())
            .stdin(Stdio::null())
            .stdout(Stdio::piped())
            .stderr(Stdio::piped())

which is different from our "inherit" way: https://github.com/containerd/rust-extensions/blob/main/crates/runc/src/lib.rs#L121

        // Default to inherited stdio, and they may be override by command options.
        cmd.stdin(Stdio::null())
            .stdout(Stdio::inherit())
            .stderr(Stdio::inherit());

Although it can be override by command options as @jiangliu said, these optios also need a pub io: Option<Arc<dyn Io>> field member, otherwise, the output may passed to partent command.

Take shim as an example, it will redirect its log message into a fifo, leaving stdio to /dev/null. So we can't get error message anymore.

I perfer using a pipe rather than inherited to avoid adding member in every options.
cc @mxpv @jiangliu

With ctr i pull --snapshotter custom docker.io/library/hello-world:latest given by the README, the snapshotter server returns a protocol error:

...
unpacking linux/amd64 sha256:97a379f4f88575512824f3b352bc03cd75e239179eea0fecc38e597b2209f49a...
ctr: failed to prepare extraction snapshot "extract-947546364-RurZ sha256:e07ee1baac5fae6a26f30cabfe54a36d3402f96afda318fe0a96cec4ca393359": stream terminated by RST_STREAM with error code: PROTOCOL_ERROR: unknown

A snippet from the snapshotter logs:

...
DEBUG [h2::codec::framed_read] received frame=Headers { stream_id: StreamId(1), flags: (0x4: END_HEADERS) }
TRACE [tracing::span::active] <- FramedRead::poll_next
TRACE [tracing::span] -- FramedRead::poll_next
TRACE [h2::proto::connection] recv HEADERS frame=Headers { stream_id: StreamId(1), flags: (0x4: END_HEADERS) }
TRACE [h2::proto::streams::flow_control] inc_window; sz=1048576; old=0; new=1048576
TRACE [h2::proto::streams::flow_control] inc_window; sz=65535; old=0; new=65535
TRACE [h2::proto::streams::streams] recv_headers; stream=StreamId(1); state=State { inner: Idle }
TRACE [h2::proto::streams::recv] opening stream; init_window=1048576
DEBUG [h2::server] malformed headers: malformed authority (b"unix:///tmp/snap2.sock"): invalid uri character
TRACE [h2::proto::streams::send] send_reset(..., reason=PROTOCOL_ERROR, initiator=Library, stream=StreamId(1), ..., is_reset=false; is_closed=false; pending_send.is_empty=true; state=State { inner: Open { local: 
AwaitingHeaders, remote: Streaming } } 
TRACE [h2::proto::streams::prioritize] clear_queue; stream.id=StreamId(1)
TRACE [tracing::span::active] -> clear_queue
TRACE [tracing::span::active] <- clear_queue
TRACE [tracing::span] -- clear_queue
...

Looks like nightly CI started failing last week: https://github.com/containerd/rust-extensions/actions with the first failure in https://github.com/containerd/rust-extensions/actions/runs/5273246763

Originally posted by @jsturtevant in #139 (comment)

Interestingly it was passing and is now failing on the same commit: 35a97f1 so something else in the dependency chain must have changed.

I tried to run the container example, but when this error happens. The container is created, but when starting the task I get an error. Here's the full output:

root@bullseye:/home/vagrant/containerd/target/debug# ./containerd 
Container: "abc123" created
thread 'main' panicked at 'Failed to create task: Status { code: Unknown, message: "OCI runtime create failed: container_linux.go:367: starting container process caused: exec: \"echo\": executable file not found in $PATH: unknown", metadata: MetadataMap { headers: {"content-type": "application/grpc"} }, source: None }', src/main.rs:104:42

It seems the files are missing.

Containerd version:

root@bullseye:/home/vagrant/containerd/target/debug# ctr version
Client:
  Version:  1.4.13~ds1
  Revision: 1.4.13~ds1-1~deb11u4
  Go version: go1.15.15

Server:
  Version:  1.4.13~ds1
  Revision: 1.4.13~ds1-1~deb11u4
  UUID: 88e1cb1e-1277-4b93-936d-ccbc7de4cb55

When I ran ctr task metric <task-name>, the container runtime returns a rpc error, indicating that the metric collecting method doesn't work on cgroup v2. I think I know the issue lies in the collect_metric method. Will have a PR to fix it.

Reproduce

➜  rust-extensions-fork git:(main) sudo ctr run --net-host --rm --runtime=io.containerd.runc.v2-rs docker.io/library/py-flask-app:latest pyflask
 * Serving Flask app 'app'
 * Debug mode: off
WARNING: This is a development server. Do not use it in a production deployment. Use a production WSGI server instead.
 * Running on all addresses (0.0.0.0)
 * Running on http://127.0.0.1:8000
 * Running on http://10.0.0.4:8000
Press CTRL+C to quit
ctr: rpc error: code = Unknown desc = ttrpc: closed: unknown

➜  runwasi git:(issue64) ✗ sudo ctr task metric pyflask         
ctr: not found