Docker fails on Fedora 36: Failed to listen on docker.socket

Ask Fedora Ask in English
,
1

Docker fails to start on Fedora 36. This is the moby-engine package, but the official docker-ce failed as well.

# systemctl restart docker.service 
A dependency job for docker.service failed. See 'journalctl -xe' for details.
...
# journalctl -xe
systemd[1]: docker.socket: Failed to determine SELinux label: Invalid argument
systemd[1]: docker.socket: Failed to listen on sockets: Invalid argument
systemd[1]: docker.socket: Failed with result 'resources'.

SELinux is already disabled as it’s not a requirement on this machine and the RPM installation failed while it was still active. So, in /etc/selinux/config SELINUX=permissive and sestatus 0.
For the record, this is how the RPM installation failed with SELinux still active:

error: lsetfilecon: (/etc/containerd, system_u:object_r:container_config_t:s0) Invalid argument
error: Plugin selinux: hook fsm_file_prepare failed

The docker.service unit depends on the docker.socket unit which fails to start.

# systemctl status docker.socket
× docker.socket - Docker Socket for the API
     Loaded: loaded (/usr/lib/systemd/system/docker.socket; enabled; vendor preset: enabled)
     Active: failed (Result: resources)
   Triggers: ● docker.service
     Listen: /run/docker.sock (Stream)

systemd[1]: docker.socket: Failed with result 'resources'.
systemd[1]: Failed to listen on docker.socket - Docker Socket for the API.

I have found other discussions with similar errors, some recommended to change kernel boot parameters. Others recommended switching to alternatives like Podman. However, I’d prefer to get Docker running without changing the kernel configuration. In fact, having to manually add the user to the docker group should be the only step that has to be performed post installation: usermod -aG docker user
That way, no reboot should be required at all. To start using Docker in a running terminal with a shell that was started before the user was added to the group, something like sudo -su user can be used to apply the group change within that terminal’s shell (run id before and after to see the difference).

2

Workaround:

As systemd fails to start docker.socket, let’s try to replace it.

The command dockerd --host=fd:// fails to start. Replacing “fd” with “unix” works though, “fd” is for systemd (doc). So this is the idea:

  1. Disable the systemd socket:
    # systemctl mask docker.socket
  2. Copy the service unit file /usr/lib/systemd/system to /etc/systemd/system/ to temporarily modify the service without changing the original file.
    cp -vi /usr/lib/systemd/system/docker.service /etc/systemd/system/docker.service
  3. In the new service unit file, replace “fd” with “unix”.
    sed -i 's!host=fd://!host=unix://!' /etc/systemd/system/docker.service
  4. Also disable the dependency on docker.socket.
    sed -i 's!^Requires=docker.socket!#Requires=docker.socket!' docker.service

Now, Docker starts:

# systemctl daemon-reload
# systemctl restart docker.service
# systemctl status docker.service
...
systemd[1]: docker.service: Changed start -> running

A real fix would be appreciated though. Is this error documented somewhere?

3

Well Fedora has Podman out of the box, and Podman already creates /run/docker.sock which is a symbolic link to /run/podman/podman.sock. I’m thinking that the system is preventing Docker from accessing / overwriting it with it’s own socket file.

2 Likes
4

Good point about Podman being preinstalled on Fedora but podman.service is disabled, so is podman.socket which is why /run/podman/podman.sock does not exist.

5

The point is that unless you specifically need docker you can instead enable the podman socket and have mostly the same (if not better) capabilities. If typing docker vs podman on the CLI is a problem, then you can also install podman-docker which will translate docker commands back to podman as well.

If for some reason you need still need classic docker and can’t use the newer podman, you’ll have better luck installing it via the Fedora repos (sudo dnf install moby-engine) than from the Docker 3rd party repos.

podman also has much better support for SELinux and rootless containers out of box, so you don’t need to keep selinux disabled.

6

@vwbusguy Your point about Podman having mostly the same capabilities is interesting, but I already wrote in my original post:

And if I just want to get a working Docker setup running on another machine, I may not have the time or motivation to replace Docker with an alternative. For example, what about docker-compose files, can they be used with Podman without any change? That’s why I focused on Docker in this discussion.

Plus sometimes I’d rather keep using a tool that works fine even if I have to fix some config bug possibly introduced by the distribution, rather than ditching that tool and migrating to a different one. Unless Docker has officially been declared as deprecated by Fedora, hence my question if this bug is documented somewhere.

That’s what I used as mentioned above:

7

Hey,

I usually hate it when I ask for help with something and the response is “Switch to X instead” however, here’s some things to know about Podman and why you might wanna consider switching:

  1. Podman is included in Fedora out of the box and is already configured to run rootless containers. You don’t even have to add your user to a group.

  2. Fedora contains a package called podman-docker which makes an alias called “docker” that points to podman and it works, because Podman was designed to be a drop in replacement.

  3. Podman can run docker-compose files without requiring any alteration to them. Install the package podman-compose then run the following commands:

systemctl --user enable podman.socket
systemctl --user start podman.socket
systemctl --user status podman.socket

And now you’re set up to run rootless containers with your compose files. If you want them to run as root, then remove the --user and add sudo to the above commands. Once you’ve done it, you’ll realize that on a fresh install of Fedora, you can have Podman configured to run your compose files within like 10 minutes.

[Edit]
4. Another plus to Podman is once you’ve created a container or pod, you can tell Podman to generate a systemd unit file for you to have it start at boot. If you deploy your container the right way, you can also have Podman auto update your container images and redeploy your containers when a new image is available.

2 Likes