Containerd: Getting started example is not working

[gabrik]

Description

The getting started example of Go client API is not working

Steps to reproduce the issue:

1. wget https://github.com/containerd/containerd/releases/download/v1.2.7/containerd-1.2.7.linux-amd64.tar.gz
2. tar -zvf containerd-1.2.7.linux-amd64.tar.gz
3. creating the base configuration file
4. adding containerd/bin to PATH
5. go build main.go
6. sudo main

Describe the results you received:

Got this error:

2019/07/31 16:35:51 runtime "io.containerd.runc.v2" binary not installed "containerd-shim-runc-v2": file does not exist: unknown

Describe the results you expected:
Something like:

1:C 04 Aug 20:41:37.682 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
1:C 04 Aug 20:41:37.682 # Redis version=4.0.1, bits=64, commit=00000000, modified=0, pid=1, just started
1:C 04 Aug 20:41:37.682 # Warning: no config file specified, using the default config. In order to specify a config file use redis-server /path/to/redis.conf
1:M 04 Aug 20:41:37.682 # You requested maxclients of 10000 requiring at least 10032 max file descriptors.
1:M 04 Aug 20:41:37.682 # Server can't set maximum open files to 10032 because of OS error: Operation not permitted.
1:M 04 Aug 20:41:37.682 # Current maximum open files is 1024. maxclients has been reduced to 992 to compensate for low ulimit. If you need higher maxclients increase 'ulimit -n'.
1:M 04 Aug 20:41:37.683 * Running mode=standalone, port=6379.
1:M 04 Aug 20:41:37.683 # WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128.
1:M 04 Aug 20:41:37.684 # Server initialized
1:M 04 Aug 20:41:37.684 # WARNING overcommit_memory is set to 0! Background save may fail under low memory condition. To fix this issue add 'vm.overcommit_memory = 1' to /etc/sysctl.conf and then reboot or run the command 'sysctl vm.overcommit_memory=1' for this to take effect.
1:M 04 Aug 20:41:37.684 # WARNING you have Transparent Huge Pages (THP) support enabled in your kernel. This will create latency and memory usage issues with Redis. To fix this issue run the command 'echo never > /sys/kernel/mm/transparent_hugepage/enabled' as root, and add it to your /etc/rc.local in order to retain the setting after a reboot. Redis must be restarted after THP is disabled.
1:M 04 Aug 20:41:37.684 * Ready to accept connections
1:signal-handler (1501879300) Received SIGTERM scheduling shutdown...
1:M 04 Aug 20:41:40.791 # User requested shutdown...
1:M 04 Aug 20:41:40.791 * Saving the final RDB snapshot before exiting.
1:M 04 Aug 20:41:40.794 * DB saved on disk
1:M 04 Aug 20:41:40.794 # Redis is now ready to exit, bye bye...
redis-server exited with status: 0

Output of containerd --version:

containerd github.com/containerd/containerd v1.2.6 894b81a4b802e4eb2a91d1ce216b8817763c29fb

Any other relevant information:

Running the same image using ctr works
Ubuntu 16.04.6
runc version 1.0.0-rc8
go version go1.12.7 linux/amd64

[gabrik]

Just as a small update, if I create v2 just by copying v1 it works
cp containerd-shim-runc-v1 containerd-shim-runc-v2

[crosbymichael]

From this and your other issue about LogFile, you don't have the current daemon installed. You are using a master containerd client running a 1.2.6 daemon do it has some discrepancies

[TheDiveO]

@crosbymichael is there some way to tell the client to downgrade to the version of the containerd daemon?

The rationale is that the containerd installation might come from the OS packages, which usually lack behind. Moreover, you might not have control over the host OS installation at all, but have to live with whatever you are faced with.

But in order to get the containerd client compiling at all, atm we need to use github.com/containerd/containerd@master. So there's plainly a catch-22 here...! :(

[xsresearch]

@TheDiveO This can be resolved by adding the line
containerd.WithRuntime("io.containerd.runtime.v1.linux", nil),
to the client.NewContainer call in the example which will allow it to run against earlier daemon versions.