Docker Community Edition docker daemon
is not supported on Linux. #701
Open
Description
Encountered the following error on Ubuntu 16.04 running docker version 17.06.0-ce.
``docker daemonis not supported on Linux. Please run
dockerd` 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.
Metadata
Assignees
Labels
No labels
Activity
grantholly commentedon Jul 3, 2017
@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 commentedon Jul 3, 2017
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 commentedon Jul 5, 2017
@grantholly yes i'd be willing to take a look at the changes and integrating into my own fork for testing.
Morsicus commentedon Jul 10, 2017
Hi,
Any news on this issue ? :)
ocastle commentedon Jul 11, 2017
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 commentedon Jul 12, 2017
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 thedocker_command
, but it's not writing out to the correct file.juliantaylor commentedon Jul 17, 2017
In addition to changing
docker_command
todockerd
, you also need to overridedaemon_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.erbLongLiveCHIEF commentedon Jul 17, 2017
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 updocker_command = 'dockerd'
.The approach I'm taking right now, is to have 3 parameters (with defaults given):
Using
daemon_subcommand
will output a deprecation warning, and shim the correct usage ofdocker daemon
vsdockerd
.This will allow compatibility with any existing downstream manifests while enabling the latest versions of docker to run.
grantholly commentedon Jul 19, 2017
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 commentedon Jul 20, 2017
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 commentedon Jul 20, 2017
@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 commentedon Jul 20, 2017
@LongLiveCHIEF go for it.
In my PR, there is no assumption that
dockerd
is installed. The way the fact works is you either get anil
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 thedockerd
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
isnil
then we'll use the olderdocker daemon
command.LongLiveCHIEF commentedon Jul 20, 2017
I like it.
davidgibbons commentedon Jul 27, 2017
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.
14 remaining items