I can never get it to work for me when its just 3 seconds.
With this change it generates the OOM message around 17 seconds, but
I increased the timeout to 30 for people with slower machines
Signed-off-by: Doug Davis <dug@us.ibm.com>
This makes `registry.Service` a first class type and does not use jobs
to interact with this type.
Signed-off-by: Michael Crosby <crosbymichael@gmail.com>
Syslog was a heading-2, but should be heading-3;
changed the headings to heading-4 to match the
"network settings" section.
Also changed "Log driver" to "logging driver" for JSON.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Closing activationLock only if it's not closed already. This is needed
only because integration tests using docker code directly and doesn't
care about global state.
Signed-off-by: Alexander Morozov <lk4d4@docker.com>
Update registry package to use the v2 registry api from distribution. Update interfaces to directly take in digests.
Signed-off-by: Derek McGowan <derek@mcgstyle.net> (github: dmcgowan)
It's about time to let folks not hit 'vfs', when 'overlay' is supported
on their kernel. Especially now that v3.18.y is a long-term kernel.
Signed-off-by: Vincent Batts <vbatts@redhat.com>
Currently the progress reader won't close properly by not setting the close size.
fixes#11849
Signed-off-by: Derek McGowan <derek@mcgstyle.net> (github: dmcgowan)
Api requesting port for daemon before init_networkdriver called.
Problem is that now initialization of api depends on initialization of
daemon and their intializations runs in parallel. Proper fix will be
just do it sequentially. For now I don't want refactor it, because it
can bring additional problems in 1.6.0.
Signed-off-by: Alexander Morozov <lk4d4@docker.com>
Do not remove container if any of the resource could not be cleaned up. We
don't want to leak resources.
Two new states have been created. RemovalInProgress and Dead. Once container
is Dead, it can not be started/restarted. Dead container signifies the
container where we tried to remove it but removal failed. User now needs to
figure out what went wrong, corrent the situation and try cleanup again.
RemovalInProgress signifies that container is already being removed. Only
one removal can be in progress.
Also, do not allow start of a container if it is already dead or removal is
in progress.
Also extend existing force option (-f) to docker rm to not return an error
and remove container from user view even if resource cleanup failed.
This will allow a user to get back to old behavior where resources
might leak but atleast user will be able to make progress.
Signed-off-by: Vivek Goyal <vgoyal@redhat.com>
Docker does not know about our named cpuacct,cpu,cpuset cgroup
hierarchy with multiple subsystems in it. So to use them with docker
in integration-cli test TestRunWithCpuset inside docker container
we need to add symlinks to them in hack/dind script.
Example:
old version of parser will do:
cat /proc/1/cgroup
11:cpu,cpuacct,name=my_cpu_cpuacct:/
...
and create and mount this hierarchy to directory
/cgroup/cpu,cpuacct,name=my_cpu_cpuacct/
so docker cannot find it because it has strange name
in new parser directory will be same as on host
/cgroup/my_cpu_cpuacct
and have symlinks for docker to find it
/cgroup/cpu -> /cgroup/my_cpu_cpuacct
/cgroup/cpuacct -> /cgroup/my_cpu_cpuacct
in other case if where is no name
cat /proc/1/cgroup
11:cpu,cpuacct:/
...
mount will be same for both parsers
/cgroup/cpu,cpuacct
and new one will also create symlinks
/cgroup/cpu -> /cgroup/cpu,cpuacct
/cgroup/cpuacct -> /cgroup/cpu,cpuacct
Signed-off-by: Pavel Tikhomirov <ptikhomirov@parallels.com>
This has a few hacks in it but it ensures that the bridge driver does
not use global state in the mappers, atleast as much as possible at this
point without further refactoring. Some of the exported fields are
hacks to handle the daemon port mapping but this results in a much
cleaner approach and completely remove the global state from the mapper
and allocator.
Signed-off-by: Michael Crosby <crosbymichael@gmail.com>
Once the job has failed and is respawned, the status becomes `docker
respawn/post-start` after subsequent failures (as opposed to `docker
stop/post-start`), so the post-start script needs to take this into
account.
I could not find specific documentation on the job transitioning to the
`respawn/post-start` state, but this was observed on Ubuntu 14.04.2.
Signed-off-by: Lewis Marshall <lewis@lmars.net>
If job "acceptconnections" is called before "serveapi" the API Accept()
method will hang forever waiting for activation. This is due to the fact
that when "acceptconnections" ran the activation channel was nil.
Signed-off-by: Darren Shepherd <darren@rancher.com>
