Maybe take this out so we can see it fail, and then rebase after #9104?

Good point. Updated!

Will it be useful to be able to selectively invoke an interceptor func based on a specific runc command? e.g. one may only want to intercept the runc exec

I think the invokerInterceptor can choose to do that already by inspecting os.Args.

Ah that's true. LGTM then.

@henry118 I don't have good idea to inject failpoint by some json settings (like shim-api-level )

So, if we have to inject failpoint during runc call, we need to add new profile code to support the specific scenario. It's not flexible but just works. Any inputs are welcomed.

@fuweid My original idea was having flexible interceptor behaviors per different subcommand of runc. So I think Sam's suggestion was valid, since a specific Interceptor's implementation could inspect or.Args to find out the runc subcommand, and choose to simply return after executing default invoker or continue to perform other actions.

I did a local testing by modifying the interceptor like this:

func issue9103KillInitAfterCreate(ctx context.Context, method invoker) error {
        return method(ctx)
}

But the test still failed:

=== RUN   TestIssue9103
    log_hook.go:47: time="2023-09-21T16:42:02.717750203Z" level=debug msg="remote introspection plugin filters" func="introspection.(*introspectionRemote).Plugins" file="/home/ubuntu/go/src/github.com/pr/containerd/services/introspection/introspection.go:46" filters="[type==io.containerd.snapshotter.v1, id==overlayfs]" testcase=TestIssue9103
    container_linux_test.go:1470:
        	Error Trace:	/home/ubuntu/go/src/github.com/pr/containerd/integration/client/container_linux_test.go:1470
        	Error:      	Not equal:
        	            	expected: "created"
        	            	actual  : "stopped"

        	            	Diff:
        	            	--- Expected
        	            	+++ Actual
        	            	@@ -1,2 +1,2 @@
        	            	-(containerd.ProcessStatus) (len=7) "created"
        	            	+(containerd.ProcessStatus) (len=7) "stopped"

        	Test:       	TestIssue9103
--- FAIL: TestIssue9103 (0.18s)
FAIL

I think there are 2 issues in this test case:

1. Since we never started the task, the expected task status should be "created";
2. The "expected" & "actual" values are confusing. I think they should be swapped?

Hi @henry118 For the first one, the #9104 reporter run into a issue that the runc-init process has been killed after runc-create returned successfully. So the process should be stopped. The failpoint is used to simulate the weird case. For the normal case, we should not use runc-fp. The case is expecting stopped status. However, your change is just creating the normal runc-init process. That's why it fails.

For the second one, yes. I will swap them.