Comment # 7 on bug 1232702 from Alexandre Vicenzi

(In reply to David Walker from comment #4)
> Well, this is still happening, but intermittently, so I looked deeper again
> and found "Oct 31 12:28:27 rpi4b dockerd[1287]: failed to start containerd:
> timeout waiting for containerd to start" in the previously attached log
> file. The docker.service has "Restart=60s", so dockerd does restart
> successfully, but in the mean time, other services that depend on
> docker.service (and don't specify the Restart option) fail on the dependency.
> 
> Looking at containerd.service, it has:
> 
>   After=network.target local-fs.target
>   Conflicts=docker.service
> 
> but docker.service has no mention of containerd:
> 
>   After=network.target lvm2-monitor.service firewalld.service
>   Wants=docker.socket
> 
> My interpretation is that after network.target is reached, both
> docker.service and container.service are eligible to start, one at a time.
> If docker.service happens to start before containerd.service, then
> containerd.service will not attempt to start until docker.service exits
> (well in this case, fails).
> 
> Should containerd.service have "Before=docker.service", in addition to
> "Conflicts=docker.service"? I'm giving it a try...

The Conflicts directive is used when you want to ensure that two or more units
do not run simultaneously. It is a mutually exclusive option.

If both services (docker and containerd) are enabled to start at boot time, the
service that starts first wins, and the other service won't start.

If you start one service while the other is active, systemd will stop the
conflicting service.

Is there a reason why you need both running at the same time?