Docker Community Edition `docker daemon` is not supported on Linux.

[ocastle]

Encountered the following error on Ubuntu 16.04 running docker version 17.06.0-ce.

``docker daemonis not supported on Linux. Please rundockerd` directly`

The ExecStart= line of the 'service-overrides-debian.conf.erb' template needs to use 'dockerd' as the command instead of 'docker daemon' when using the Community Edition. Editing the value and reloading the systemd daemon confirmed. Puppet run will revert the change, but daemon will continue running until restarted and require the same change to restore service.

[grantholly]

@ocastle would you be willing to test out some changes that I have in a fork? I've been having the same problem with CentOS and docker 17.06.0-ce, but I've hacked together a workaround. Its in my fork https://github.com/grantholly/garethr-docker.

[vladgh]

From my tests, the latest docker (docker-ce_17.06.0~ce-0~ubuntu) on Xenial does not use the /etc/systemd/system/docker.service.d/service-overrides.conf file. The workaround for me was to delete that file altogether, rather than modifying /usr/bin/docker daemon to /usr/bin/dockerd.

I'm not sure, but I think /lib/systemd/system/docker.service is used instead.

[ocastle]

@grantholly yes i'd be willing to take a look at the changes and integrating into my own fork for testing.

[Morsicus]

Hi,

Any news on this issue ? :)

[ocastle]

The changes from @grantholly were integrated into the working fork used for testing and were verified to solve the issue faced on Ubuntu:16.04

[LongLiveCHIEF]

The workaround for me was to delete that file altogether, rather than modifying /usr/bin/docker daemon to /usr/bin/dockerd.

This is related to #703 & #698. You actually shouldn't have to manually perform any workarounds, and should instead be able to pass in dockerd as the docker_command, but it's not writing out to the correct file.

[juliantaylor]

In addition to changing docker_command to dockerd, you also need to override daemon_subcommand to an empty string to get a correct service file override. See https://github.com/garethr/garethr-docker/blob/master/templates/etc/systemd/system/docker.service.d/service-overrides-debian.conf.erb

[LongLiveCHIEF]

Yep, already got that one. Here's what I've done so far.

The challenge I'm working through as we speak is the dual nature of docker_command usage in the module.

In the manifests/run.pp, manifests/image.pp, manifests/exec.pp, etc... docker_command is used as a client library. I can't just change up docker_command = 'dockerd'.

The approach I'm taking right now, is to have 3 parameters (with defaults given):

$docker_command = 'docker'
$daemon_command = 'dockerd'
$daemon_subcommand = undef

Using daemon_subcommand will output a deprecation warning, and shim the correct usage of docker daemon vs dockerd.

This will allow compatibility with any existing downstream manifests while enabling the latest versions of docker to run.

[grantholly]

Is there a preference for making $docker_command work over using facter to figure how to call the docker daemon? I could go either way. I have a pull request open (#704) that fixes this issue and has been checked to work with at least Ubuntu and CentOS. It could use some review.

[LongLiveCHIEF]

I reviewed the PR, and the only flaw I see is in the assumption that you're always going to have dockerd available. We'd have to declare that this module only supports specific versions of docker, deprecating support for versions of docker > 1.12.

I'm also not certain that the facter technique will work with custom build versions of docker (example being docker-latest package that is released for RedHat family OS's).

[LongLiveCHIEF]

@grantholly would you mind if I pulled your PR (#704) into my fork? While I think it can't do the job on it's own, it will work for like 99% of cases, and will serve as a much more solid base than just assuming /usr/lib/... inside the template files, (which has been bothering me for a while now.)

[grantholly]

@LongLiveCHIEF go for it.

In my PR, there is no assumption that dockerd is installed. The way the fact works is you either get a nil value for $dockerd_binary, as you would in the case of running an older version of docker, or you would get a string value containing the path to the dockerd binary. Here's the details on Facter::Core::Execution#which (http://www.rubydoc.info/gems/facter/2.4.6/Facter/Core/Execution#which-class_method)

In the unit file templates, (https://github.com/garethr/garethr-docker/pull/704/files#diff-7dae3e5d9fd27c34844a4d6e0485e2e0L8) and (https://github.com/garethr/garethr-docker/pull/704/files#diff-1ae24078d52aa1e01fa570dd84a1efddR5) there's a boolean check for the binary. If $dockerd_binary is nil then we'll use the older docker daemon command.

[LongLiveCHIEF]

I like it.

[davidgibbons]

That nil value seems to generate a broken systemd file though?

Specifically the first run facter will return no value. As it runs before the package is installed.