Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
server: Add socket activation #3105
This adds the ability to socket activate docker by passing in
The fastest way to test this is to run:
This PR is an updated version of #2054
oh boy @philips you're going to need to help me here, by adding some documentation - both to the commands.go -? help, and to the cli.rst.
in the cli.rst case, we need to tell the user under what circumstances they should choose which (mix) of the 3 options, and what the possible issues are.
referenced this pull request
Dec 13, 2013
@jamtur01 I though so to originally, but now I wonder if this is something only very few people will be setting up (ie packagers and a few that make custom systemd setups). If that is the case, then adding too much information to our docco will confuse more.
that said - I know little about Systemd - so I don't really feel confident about it.
"Using socket activation has the advantage that the socket file is immediately available for
Is this sufficient?
@philips is this PR about systemd specific socket stuff, or does this apply to all systems?
What are 'systems using socket activation' - and how would the docker user know?
its really not clear to me from what you wrote.
Also - whats the disadvantage? Again, if what you wrote is the entire story, it reads like we don't need the other 2 types of socket.
using my best guesses, as I'm a luddite :)
I presume that means that containers are not automatically restarted at boot (unlike now)
I also wonder what happens when the first docker client runs
On Sun, Dec 15, 2013 at 6:36 PM, Sven Dowideit email@example.com wrote:
It is "systemd specific" in that systemd is the only init system that
As I mentioned above the only people who are really going to care
There is no disadvantage on systems that support socket activation. It
Sure, if you want that feature you have to start docker up at boot. In
The socket exists and all requests will queue in the internal Kernel
@canoon lxc needs it and it is from the original systemd unit file: https://github.com/dotcloud/docker/blob/master/contrib/init/systemd/docker.service
added a commit
this pull request
Jan 28, 2014
I am not sure if this fixes my issue, or if it just changes what I need to know. Maybe someone can answer while the change is still freshly merged and in your memory? I was having a problem starting docker containers with systemd using a simple unit like this:
The container/service would start successfully on demand, but fail on boot, not giving
Worked around by adding a
So, can I just take it out when this gets merged into a release upstream, at CoreOS?