/etc/default/docker format is wrong for systemd service

[Scott Moser]

If you install docker.io from archive, you get /etc/default/docker populated with a string like:
#
# If you need Docker to use an HTTP proxy, it can also be specified here.
# export http_proxy=http://localhost:3128/

Simply uncommenting that line and adjusting to your http host will not work.

This is because that file is loaded as an EnviornmentFile by systemd in /lib/systemd/system/docker.service
 EnvironmentFile=-/etc/default/docker

And apparently, systemd silently ignores the line because it is not <key>=<value>

To fix this, you have to:
http_proxy=http://your.proxy:3128/
rather than
export http_proxy=http://your.proxy:3128

I'm not sure if this is easily accomplished or not while retaining support for that file being loaded by sysvinit also.

ProblemType: Bug
DistroRelease: Ubuntu 15.10
Package: docker.io 1.6.2~dfsg1-1ubuntu2 [modified: lib/systemd/system/docker.service]
ProcVersionSignature: User Name 3.19.0-22.22-generic 3.19.8-ckt1
Uname: Linux 3.19.0-22-generic x86_64
ApportVersion: 2.17.3-0ubuntu4
Architecture: amd64
Date: Fri Jun 26 14:57:10 2015
Ec2AMI: ami-0000043a
Ec2AMIManifest: FIXME
Ec2AvailabilityZone: nova
Ec2InstanceType: m1.small
Ec2Kernel: aki-00000002
Ec2Ramdisk: ari-00000002
ProcEnviron:
 TERM=screen
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=<set>
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: docker.io
UpgradeStatus: No upgrade log present (probably fresh install)
mtime.conffile..etc.default.docker: 2015-06-26T14:56:57.885900

[Robie Basak (racb)]

Yeah this is valid - I've hit it myself. Should be sent to Debian for appropriate resolution regardless of init system in use.

[Guido Maria Serra (zeph1ro)]

not only... the variables that are in /etc/default/systemd are not being used by the docker.system file

I had to add the EnvironmentFile key (after having seen this thread/bug report)
 and also the $DOCKER_OPTS in the ExecStart value [originally it is NOT there]

[Unit]
Description=Docker Application Container Engine
Documentation=https://docs.docker.com
After=network.target docker.socket
Requires=docker.socket

[Service]
Type=notify
EnvironmentFile=-/etc/default/docker
ExecStart=/usr/bin/docker daemon $DOCKER_OPTS -H fd://
MountFlags=slave
LimitNOFILE=1048576
LimitNPROC=1048576
LimitCORE=infinity

[Install]
WantedBy=multi-user.target

[Kick In (kick-d)]

Hi Guido Serra,

Which version of docker did you install ? The one from ubuntu wily archive?

I just installed docker.io from archive on a wily vm, and I got this systemd unit:

docker.io 1.6.2~dfsg1-1ubuntu3 amd64 Linux container runtime

[Unit]
Description=Docker Application Container Engine
Documentation=http://docs.docker.com
After=network.target docker.socket
Requires=docker.socket

[Service]
EnvironmentFile=-/etc/default/docker
ExecStart=/usr/bin/docker -d -H fd:// $DOCKER_OPTS
MountFlags=slave
LimitNOFILE=1048576
LimitNPROC=1048576
LimitCORE=infinity

[Install]
WantedBy=multi-user.target

[Michael Hudson-Doyle (mwhudson)]

I also like the way /etc/default/docker says that the file does not apply to systemd, except in fact it does, kinda. For the export/sysvinit problem, one approach would be to put set -a / set +a around the sourcing of /etc/default/docker?

[Tianon Gravi (tianon)]

IMO we should just remove the patch we add that makes it apply; systemd
drop in files are the way systemd upstream recommends configuring startup
parameters like this, which is why upstream doesn't include the
EnvironmentFile directive that we've patched in.

[Michael Hudson-Doyle (mwhudson)]

Yeah, I think that makes sense. We want to deliver an "upstream" experience with docker, not a Debian/Ubuntu-ized one.

[Tianon Gravi (tianon)]

https://anonscm.debian.org/cgit/docker/docker.io.git/commit/?id=0bc5ad426c84804c939804e33247140ff2636991 is the compromise I've applied in Debian recently (replacing the file's contents with a long-form note pointing our users to the upstream-recommended alternatives, which should invoke dpkg's configuration file merge and also not break existing users right away).

[Michael Hudson-Doyle (mwhudson)]

Makes sense to me, although I *think* I'd be just as happy with the "just don't source that file" approach ...

[Tianon Gravi (tianon)]

Yeah, I agree and want to get there, but I figured just dropping it straight away would be doing our users a disservice (especially since it might not be obvious right away that it's not being used anymore).

For example, if a user has "--bip=..." set in DOCKER_OPTS in that file, then dropping the sourcing of it outright wouldn't cause the service to fail to start or anything, and it actually wouldn't change anything for the running system until the next reboot (at which time, Docker would revert back to choosing its own IP range, which will be a nasty surprise for said operator). :(

[Michael Hudson-Doyle (mwhudson)]

Fixed in 1.11.2-0ubuntu6