[bug]failed to start runv container with docker daemon

[WeiZhang555]

I've tried to add runv as a second runtime for docker daemon, then start runv container but failed, I added some debug point and got error during runv create

failed to create container: fork/exec /xxxx/xxxx/runv/runv: operation not permitted

I've tried to debug this, and find that if I remove one line,

diff --git a/create.go b/create.go
index 33fc64a..f1f9d74 100644
--- a/create.go
+++ b/create.go
@@ -341,8 +343,8 @@ func ociCreate(context *cli.Context, container string, createFunc func(stdin, st
                        Stdout: tty,
                        Stderr: tty,
                        SysProcAttr: &syscall.SysProcAttr{
-                               Setctty: tty != nil,
-                               Setsid:  true,
+                               //Setctty: tty != nil,
+                               Setsid: true,
                        },
                }
                err = cmd.Start()

Everything works except small error:

$ docker run -ti --runtime runv busybox sh
set winsize failed, rpc error: code = Unknown desc = Error: 
                                                            / # 

I know this is not the right fix, but provide this information for your debug, hope this can be fixed soon.

[WeiZhang555]

Find some links that may related to this: golang/go#2647

[laijs]

TIOCSCTTY int arg
              Make  the  given  terminal  the controlling terminal of the
              calling process.  The calling process  must  be  a  session
              leader  and  not  have  a controlling terminal already.  If
              this terminal is already the controlling terminal of a dif‐
              ferent  session  group  then  the  ioctl  fails with EPERM,
              unless  the  caller  is  root  (more  precisely:  has   the
              CAP_SYS_ADMIN  capability)  and arg equals 1, in which case
              the terminal is stolen, and all processes that  had  it  as
              controlling terminal lose it.

I don't see any thing wrong with the usage only except when runv-containerd opens it earlier than runv-shim as #536 said. But runv-containerd is gone now.