GNU bug report logs - #38432
dockerd is not started automatically

Previous Next

Package: guix;

Reported by: andreoss <at> SDF.ORG

Date: Fri, 29 Nov 2019 23:15:02 UTC

Severity: normal

Merged with 55936

Done: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: Danny Milosavljevic <dannym <at> scratchpost.org>
Cc: andreoss <at> SDF.ORG, 38432 <at> debbugs.gnu.org
Subject: bug#38432: dockerd is not started automatically
Date: Mon, 01 Jun 2020 20:59:50 -0400
[Message part 1 (text/plain, inline)]
Hi Danny!

Danny Milosavljevic <dannym <at> scratchpost.org> writes:

> Hi Maxim,
>
> On Sun, 31 May 2020 23:27:30 -0400
> Maxim Cournoyer <maxim.cournoyer <at> gmail.com> 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:

[0001-gnu-services-docker-Add-a-debug-parameter.patch (text/x-patch, attachment)]
[Message part 3 (text/plain, inline)]
Maxim

This bug report was last modified 2 years and 314 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.