Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Warning when using an unsupported version of Linux #268

Open
ianlewis opened this issue May 31, 2019 · 10 comments
Open

Warning when using an unsupported version of Linux #268

ianlewis opened this issue May 31, 2019 · 10 comments
Labels
area: usability Issue related to usability priority: p3 Low priority type: enhancement New feature or request

Comments

@ianlewis
Copy link
Contributor

gVisor fails in unintuitive ways when run on an older version of Linux. We should print a warning or simply fail if he version of Linux used is less than the currently supported version.
@ianlewis ianlewis added type: enhancement New feature or request priority: p3 Low priority area: usability Issue related to usability labels May 31, 2019
@ianlewis ianlewis changed the title gVisor should provide a warning when using an unsupported version of Linux Warning when using an unsupported version of Linux May 31, 2019
@ianlewis
Copy link
Contributor Author

Currently runsc fails with an error like the following because the kernel is missing the memfd_create syscall which was added in Linux 3.17

OCI runtime create failed: unable to retrieve OCI runtime error (open /run/containerd/io.containerd.runtime.v1.linux/moby/2779a57fb4979db21996621118dd72bf58842937f0de04613184e8b68f2659bc/log.json: no such file or directory): /usr/local/bin/runsc did not terminate sucessfully: unknown.

See #100

@prattmic
Copy link
Member

In theory, we do have a warning: https://github.com/google/gvisor/blob/master/pkg/sentry/memutil/memutil_unsafe.go#L34

I know the plumbing all the way up to the Docker CLI worked when that was added, but it must have regressed since then.

@fvoznika
Copy link
Member

fvoznika commented Jun 3, 2019

I think it broke when a synchronization point was added to sandbox.New(). It will be fixed with: https://gvisor-review.git.corp.google.com/c/gvisor/+/18260

@ianlewis ianlewis self-assigned this Aug 14, 2020
@25077667
Copy link

25077667 commented Sep 26, 2021 •
edited

Hi all,

I traced this issue from here
My machine said xxx/log.json: no such file or directory, like this:
image

However, It supports memfd_create syscall.
I have no idea what's happened?

And my gVisor version is: "Version release-20210906.0"

@fvoznika
Copy link
Member

I believe you're running into #5865 (you need to enable cgroup v1 controller). If you run sudo runsc do echo 123 you should get a more decent error message.

@outis151
Copy link

This is something that also occurs when running inside unprivileged LXC containers (Kernel 5.10) , but I haven't figured out why that is yet. There shouldn't be any reason why that syscall is blocked there...

I0411 20:24:11.652735  1453859 main.go:219] ***************************
I0411 20:24:11.652910  1453859 main.go:220] Args: [/usr/local/bin/runsc --debug --debug-log=/tmp/runsc-debug.log --strace --log-packets --root /var/run/docker/runtime-runc/moby --log /run/containerd/io.containerd.runtime.v2.task/moby/c5d4227bdbf1811fb7e9d8a4619a773e9ed65e87a857662549c86c1b272ab3d6/log.json --log-format json delete --force c5d4227bdbf1811fb7e9d8a4619a773e9ed65e87a857662549c86c1b272ab3d6]
I0411 20:24:11.652948  1453859 main.go:221] Version release-20220228.0
I0411 20:24:11.652957  1453859 main.go:222] GOOS: linux
I0411 20:24:11.652979  1453859 main.go:223] GOARCH: amd64
I0411 20:24:11.652989  1453859 main.go:224] PID: 1453859
I0411 20:24:11.652999  1453859 main.go:225] UID: 0, GID: 0
I0411 20:24:11.653007  1453859 main.go:226] Configuration:
I0411 20:24:11.653015  1453859 main.go:227] 		RootDir: /var/run/docker/runtime-runc/moby
I0411 20:24:11.653024  1453859 main.go:228] 		Platform: ptrace
I0411 20:24:11.653038  1453859 main.go:229] 		FileAccess: exclusive, overlay: false
I0411 20:24:11.653062  1453859 main.go:230] 		Network: sandbox, logging: true
I0411 20:24:11.653072  1453859 main.go:231] 		Strace: true, max size: 1024, syscalls: 
I0411 20:24:11.653081  1453859 main.go:232] 		VFS2 enabled: true, LISAFS: false
I0411 20:24:11.653099  1453859 main.go:233] 		Debug: true
I0411 20:24:11.653107  1453859 main.go:234] ***************************
D0411 20:24:11.653156  1453859 state_file.go:52] Load container, rootDir: "/var/run/docker/runtime-runc/moby", id: {SandboxID: ContainerID:c5d4227bdbf1811fb7e9d8a4619a773e9ed65e87a857662549c86c1b272ab3d6}, opts: {Exact:false SkipCheck:false}
W0411 20:24:11.653342  1453859 delete.go:74] couldn't find container "c5d4227bdbf1811fb7e9d8a4619a773e9ed65e87a857662549c86c1b272ab3d6": file does not exist
I0411 20:24:11.653413  1453859 main.go:250] Exiting with status: 0

With this docker daemon.json:

{
    "runtimes": {
        "runsc": {
            "path": "/usr/local/bin/runsc"
        },
        "runsc-debug": {
            "path": "/usr/local/bin/runsc",
            "runtimeArgs": [
                "--debug",
                "--debug-log=/tmp/runsc-debug.log",
                "--strace",
                "--log-packets"
            ]
        }
    },
    "storage-driver": "fuse-overlayfs"
}

@ianlewis
Copy link
Contributor Author

@outis151 I'm not totally sure that's the same problem. runsc needs root in order to run for a few reasons. You can try running it in an unprivileged context (e.g. as an non-root user) using the --rootless flag and see if that works for you though there are some caveats like you can't use host networking and a few others I think.

@outis151
Copy link

runsc is actually running as root user inside the user namespace of the lxc container which is unprivileged. The result is the same running it with the --rootless flag. I am suspecting that this may be a cgroup problem

@ianlewis
Copy link
Contributor Author

@outis151 yes, by root I mean a privileged root user. --rootless will skip using cgroups for the reason you are alluding to. While it still could be cgroup related, if you're getting the same result when using it then I'm guessing that your problem lies elsewhere.

gvisor/runsc/container/container.go

Lines 1279 to 1290 in bf86207

func cgroupInstall(conf *config.Config, cg cgroup.Cgroup, res *specs.LinuxResources) (cgroup.Cgroup, error) {
if err := cg.Install(res); err != nil {
switch {
case errors.Is(err, unix.EACCES) && conf.Rootless:
log.Warningf("Skipping cgroup configuration in rootless mode: %v", err)
return nil, nil
default:
return nil, fmt.Errorf("configuring cgroup: %v", err)
}
}
return cg, nil
}

aside: I was actually wrong. You can't only use host networking or no networking with --rootless

gvisor/runsc/cmd/run.go

Lines 70 to 73 in 4e99f17

if conf.Rootless {
if conf.Network == config.NetworkSandbox {
return Errorf("sandbox network isn't supported with --rootless, use --network=none or --network=host")
}

@outis151
Copy link

Thanks for the suggestions. Will continue trying to find what is causing this

@ianlewis ianlewis removed their assignment Nov 16, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
area: usability Issue related to usability priority: p3 Low priority type: enhancement New feature or request
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@ianlewis @prattmic @fvoznika @outis151 @25077667