Hi Danny! Danny Milosavljevic writes: > Hi Maxim, > > On Sun, 31 May 2020 23:27:30 -0400 > Maxim Cournoyer wrote: > >> time="2020-05-31T22:28:15.885343166-04:00" level=warning msg="failed >> to load plugin io.containerd.snapshotter.v1.aufs" error="modprobe >> aufs failed: "modprobe: FATAL: Module aufs not found in directory >> /lib/modules/5.4.43-gnu\n": exit status 1" > > We don't have aufs, but it's not mandatory anyway. > >> The only new lines to appear in docker.log following my last reboot are: >> >> --8<---------------cut here---------------start------------->8--- >> time="2020-05-31T22:28:13.579626539-04:00" level=info msg="Starting up" >> failed to start containerd: exec: "containerd": executable file not found in $PATH >> --8<---------------cut here---------------end--------------->8--- >> >> So, it seems the failure is related to kernel modules not being found >> where they are looked for? > > I don't think so this time, at least according to these logs. > > Could it be that containerd takes too long to start up or something? And then it > tries to start it on its own? > > To find out, try adding sleep to gnu/services/docker.scm docker-shepherd-service > before make-forkexec-constructor, to make it read > > #~(begin > (sleep 2) > (make-forkexec-constructor .... It looks like this! Which is weird, because containerd doesn't take much time to start, even when networking is not yet functional (I suspected something like this at first). I wonder what we can do here... looks like we need to poll containerd to know when it's ready in the start procedure of dockerd (unless I'm missing something fancier that Shepherd would allow doing). Else we could let dockerd spawn its own containerd daemon, which it can do if we tell it where it is. Thoughts? I've made the following changes while troubleshooting this. It only printed a couple more lines, but I guess it's nice to have: