When I use runc and criu 3.9, it crashed

[yangzhao02]

Description

In runc/libcontainer/criu_linux.go, there is the following Restore function (line 618-line 796).
On line 716-line 718, there is the following content:

...
func (c *Container) Restore(process *Process, criuOpts *CriuOpts) error {
	const logFile = "restore.log"
        if err := c.handleRestoringNamespaces(req.Opts, &extraFiles); err != nil {
            return err
        }
...

This function will call the handleRestoringNamespaces function in runc/libcontainer/criu_linux.go (line 209-line 246), and on line 219, it will further call handleRestoringExternalNamespaces (runc/libcontainer/criu_linux.go line 247-line 276). On line 248, there is the following code:

func (c *Container) handleRestoringExternalNamespaces(rpcOpts *criurpc.CriuOpts, extraFiles *[]*os.File, t configs.NamespaceType) error {
    if !c.criuSupportsExtNS(t) {
        return nil
    }
...

This criuSupportsExtNS function is located at runc/libcontainer/criu_linux.go: line 167-line 181, with the following content:

func (c *Container) criuSupportsExtNS(t configs.NamespaceType) bool {
    var minVersion int
    switch t {
    case configs.NEWNET:
        // CRIU supports different external namespaces with different released CRIU versions.
        // For network namespaces to work we need at least criu 3.11.0 => 31100.
        minVersion = 31100
    case configs.NEWPID:
        // For PID namespaces criu 31500 is needed.
        minVersion = 31500
    default:
        return false
    }

    return c.checkCriuVersion(minVersion) == nil
}

When the CRIU version is lower than the minVersion, criuSupportsExtNS will return false, and handleRestoringExternalNamespaces will return nil. Consequently, in the Restore function (line 716-line 718), it will evaluate err == nil and then continue executing the subsequent logic of the Restore function. However, if the CRIU version does not meet the requirements, will continuing the execution of the Restore function (runc/libcontainer/criu_linux.go: line 716-line 718) lead to some unpredictable behaviors? Should we consider directly terminating the execution of the Restore function and return an appropriate error message when the CRIU version does not satisfy the runc requirements?

Steps to reproduce the issue

1. Install criu 3.14
2. docker container start --checkpoint-dir xxx ${containerId}

Describe the results you received and expected

runc does not stop or report an error, and then it crashed

What version of runc are you using?

1.1.3

Host OS information

centos 8

Host kernel information

5.10.134-15.2.al8.x86_64

[kolyshkin]

@adrianreber ptal

[cyphar]

Also, it should be noted the runc version is 1.1.3, which is more than 2 years old. Can you try with the latest 1.1.13 (and 1.2.0-rc2 if possible)?

[yangzhao02]

Also, it should be noted the runc version is 1.1.3, which is more than 2 years old. Can you try with the latest 1.1.13 (and 1.2.0-rc2 if possible)?

It's really nice to get your reply. I used the latest runc, but it also occured. And I look for the latest code, it seems there is no fix for this problem.
Best wishes.

[adrianreber]

@yangzhao02 From your description it sounds like you are right. The latest version of CRIU in CentOS Stream 8 (before going EOL) was CRIU 3.15, so I am curious what your setup is. From CRIU upstream we would always suggest using the latest version anyway. RHEL 8 and clones have 3.18. Your analysis seems to be correct but unlikely too happen with most distributions as usually CRIU packages are newer.