Dockerd uses systemd containerd without --containerd argument

General
1

On one of my systems, dockerd is using the systemd-managed containerd (via a socket /run/containerd/containerd.sock). On another system it’s using its own instance via a socket /run/docker/containerd/containerd.sock.

Docker was not started with --containerd argument and it hasn’t got a /etc/docker/dameon.json file.

So I’m puzzled why it’s using the system containerd rather than its own. The docs suggest that the --containerd option is required to make it work like that. Or does it see there’s a systemwide instance and choose to use it without being told?

What am I missing?

2

What is the difference between those systems? What are the docker versions? Can you check the path of the running containerd? is that also different or only the socket? I would also check the packages like this way on a debian based system:

dpkg -l | grep 'docker\|containerd'
3

Both systems are ArchLinux.

The system where it’s using system containerd is a server, last updated Sun Apr 4 18:57:36 2021

  • Docker version 20.10.5, build 55c4c88966, commandline is /usr/bin/dockerd -H fd://
  • containerd github.com/containerd/containerd v1.4.4 05f951a3781f4f2c1911b05e61c160e9c30eaa8e.m commandline is /usr/bin/containerd
  • only socket is /run/containerd/containerd.sock
  • packages docker 1:20.10.5-1 and containerd 1.4.4-1
  • no /etc/docker/daemon.json
  • docker systemd service ExecStart=/usr/bin/dockerd -H fd://
  • containerd systemd service ExecStart=/usr/bin/container

The system where it’s using a child containerd is a workstation laptop, last updated Wed Feb 16 17:43:13 2022

  • Docker version 20.10.12, build e91ed5707e /usr/bin/dockerd -H fd://
  • containerd github.com/containerd/containerd v1.6.0 39259a8f35919a0d02c9ecc2871ddd6ccf6a7c6e.m, commandline is containerd --config /var/run/docker/containerd/containerd.toml --log-level info
  • only socket is /run/docker/containerd/containerd.sock
  • packages docker 1:20.10.12-1 and containerd 1.6.0-2
  • docker systemd service ExecStart=/usr/bin/dockerd -H fd://
  • containerd systemd service is disabled and inactive

The server’s due an update and I’m trying to get it cleaned up beforehand (hence the recent questions!).

Thanks for your help.

4

ArchLinux is not a supported platform. I suppose you used “pacman” to install Docker. Am I right? I don’t have an ArchLinux to try so I don’t know how it installs Docker and when and why the installation can be different.

I can see that on your workstation containerd is disabled and inactive. It is possible that Docker on ArchLinux starts its own containerd, because the system wide containerd could not be started for some reason. I wanted to try it before I saw your response, but I realized, I can’t deletecontainerd without deleting Docker and I can’t stop and disable containerd, because systemd starts it when I start Docker or run a container (in case I stop containerd after starting Docker).

It is also possible that it works differently because the Docker versions are different and the newer release (not created by Docker) is just works differently.

Sorry fo guessing a lot :slight_smile:

5

I did use pacman, yes. I’ve just quickly checked the package build config and can’t see anything obvious. I’ll do more digging to see what I can find.

6

I did some digging around today and dockerd does not start containerd if it is already running (from what I can tell, this is determined by the existence of the socket /run/containerd/containerd.sock).

You can see this in debug log:

Containerd not running, starting daemon managed containerd
libcontainerd: started new containerd process" pid=615962
ccResolverWrapper: sending update to cc: {[{unix:///var/run/docker/containerd/containerd.sock  <nil> 0 <nil>}] <nil> <nil>}" module=grpc

whereas, if containerd is already running only the last line appears but with different socket path:

ccResolverWrapper: sending update to cc: {[{unix:///run/containerd/containerd.sock  <nil>
0 <nil>}] <nil> <nil>}" module=grpc

I think the code is here: moby/daemon_unix.go at master · moby/moby · GitHub

Unless I’ve missed it, this feature is undocumented.

1 Like