#3453·runc

Feature Request: Support Two Phases to Start Exec Process like Init

Author: fuweidCreated Apr 9, 2022Updated Jul 17, 2026

Currently, the exec-process is created by runc-exec one command. The common container engine layer will care about the exit code of exec-process, which required that the runc-exec's parent process must be the subreaper.

Since pidfd_open(2) is available, we can watch the exit event by pidfd and retrieve the exit code provided bpf sched_process_exit tracepoint. The PID=1, like systemd, will be reaper of exec-process. So, the common container engine is not required to be subreaper of exec-process, like what embedshim containerd plugin does. However, non-subreaper mode requires that exec-process starts in two phases.

  1. Fork: Setup and waiting for the exec.fifo event

    • container engine opens pidfd and trace it by eBPF
  2. Exec: Signal the init and start to exec

Currently, embedshim uses runc-exec wrapper command to be temporary subreaper to sync the status, like:

[ runc-exec-ext(child, after finish runc-exec)]		            [     embedshim(parent)    ] 

	SyncExecPid		                      -->	           Read exec-process pid

                                                      <--                SyncExecPidDone
	
    SyncExecPidStatus		                      -->	         Get exec-process current status
	
					             <--	            SyncExecPidStatusDone

It is heavy mode to start exec-process for non-subreaper, so I file this issue to request the feature for two phases to exec-process:

  • runc exec-create
  • runc exec-start

Looking foraward to the feedback! Thanks!