Hi,
Tianon Gravi wrote (04 Mar 2015 17:10:07 GMT) :
> This would definitely need to be proposed upstream (see "contrib/init"
> in the upstream repo),
I'll let you handle that: I merely worked on this bug to give a hand
and help a bit polish Jessie (and more specifically, the transition to
systemd), but I don't suffer from it myself... so far.
> but I don't know that it'll gain much support
> since the "EnvironmentFile" line in our docker.service file is a
> Debian-specific patch, and upstream recommends that systemd users
> instead use the standard systemd modification mechanism of skeleton
> service overrides in /etc/systemd [1].
Fair enough. So, our Debian-specific patch that introduces
EnvironmentFile= is partially buggy, in that it lets the user believe
that they can use /etc/default/docker to configure the daemon's
behaviour, which isn't the case for all documented options.
Assuming that nobody proposes the changes I've suggested upstream,
or that upstream rejects it (which I would fully understand), then
I see two ways out:
a) Drop the EnvironmentFile= support, on the grounds that it's
incomplete and misleading. Then document in README.Debian that
under systemd:
- /etc/default/docker is ignored (and maybe make that file point
to README.Debian);
- one can customize the daemon startup options and runtime
environment via the standard systemd drop-in override mechanism.
b) Make it clear, in /etc/default/docker, which options take effect
when running under systemd, and which ones don't. And add a note
about the Environment= directive that allows to set the latter
(http_proxy, TMPDIR); this note could live in /etc/default/docker
and/or in README.Debian.
Plan (b) seems quite acceptable, and perhaps easier to implement.
Plan (a) feels cleaner, more consistent, and easier to grasp by the
user IMO.
Cheers,
--
intrigeri
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
