When we tag an Image with several names and we run one of them,
The "create" job will log this event with
+job log(create, containerID, Imagename).
And the "Imagename" is always the first one (sorted). It is the
same to "start/stop/rm" jobs. So use the correct name instand.
This PR refer to #10479
Signed-off-by: Liu Hua <sdu.liu@huawei.com>
Upstream-commit: 663d9130118548c648c4463bae088fd983099e08
Component: engine
Right now we try device removal at the interval of 10ms and keep on trying
till either device is removed or 10 seconds are over. That means if device
is busy, we will try 1000 times in those 10 seconds.
Sounds too high a frequency of deivce removal retrial. All the logs are
filled easily. I think it is a good idea to slow down a bit and retry at
the interval of 100ms instead of 10ms.
Signed-off-by: Vivek Goyal <vgoyal@redhat.com>
Upstream-commit: c737800b7faced4b53854c8cb6766ebe58a3c3e9
Component: engine
During device removal, we are first waiting for device to close() in a tight
loop for 10 seconds. I am not sure why do we need it. First of all we come
here once the umount() is successful so device should be free. For some reason
of device is temporarily busy, then removeDevice() logic retries device removal
logic in a loop for 10 seconds and that should cover it. Can't see why one
more 10 seoncds loop is required before attempting device removal.
One loop should be able to cover all the temporary device busy conditions and
if condition is not temporary then 10 seconds loop is not going to help anyway.
So instead of two loops of 10 seconds each, I am converting it to a single
loop of 20 seconds. May be 10 second loop is good enough but for now I am
keeping it 20 seconds to avoid any regressions.
Signed-off-by: Vivek Goyal <vgoyal@redhat.com>
Upstream-commit: f74d12012c21349b2bd51d9c395a99331ff0a9a5
Component: engine
Currently in device removal path (device deactivation), we wait
for 10 seconds for devive to actually go away. waitRemove().
In current code this is not required. If dm removal task has completed
and one has done the wait on udev cookie, then device is gone and there
is no need to write another loop to wait for device removal.
This patch removes the waitRemove() which waits for 10 seconds after
device removal. This seems unnecessary.
Signed-off-by: Vivek Goyal <vgoyal@redhat.com>
Upstream-commit: dbf04ec4e2a6b4fe73f7f300918a906c0ff1a37b
Component: engine
devmapper graph driver retries device removal 1000 times in case of failure
and if this fills up console with 1000 messages (when daemon is running in
debug mode). So remove these debug messages.
Signed-off-by: Vivek Goyal <vgoyal@redhat.com>
Upstream-commit: cb7c893275c32ddfa775c3f22869a9c211024c71
Component: engine
There are issues with libdm logging. Right now if docker daemon is run
in debug mode, logging by libdm is too verbose. And if a device can't
be removed, thousands of messages fill the console and one can not see
what's going on.
This patch removes devicemapper.LogInitVerbose() call as that call will
only work if docker was not registering its own log handler with libdm.
For some reason docker registers one with libdm and libdm hands over
all the messages to docker (including debug ones). And now it is up to
devmapper backend to figure out which ones should go to console and
which ones should not.
So by default log only fatal messages from libdm. One can easily modify
the code to change it for debugging purposes.
Signed-off-by: Vivek Goyal <vgoyal@redhat.com>
Upstream-commit: e07d3cd9acf14219f33e12375fb8c2e3fe02ad0c
Component: engine
I have seen a lot of people try to do this and reach out to me on how to mount
/dev/snd because it is returning "not a device node". The docs imply you can
_just_ mount /dev/snd and that is not the case. This fixes that. It also allows
for coolness if you want to mount say /dev/usb.
Docker-DCO-1.1-Signed-off-by: Jessie Frazelle <hugs@docker.com> (github: jfrazelle)
Docker-DCO-1.1-Signed-off-by: Jessie Frazelle <princess@docker.com> (github: jfrazelle)
Docker-DCO-1.1-Signed-off-by: Jessie Frazelle <jess@docker.com> (github: jfrazelle)
Docker-DCO-1.1-Signed-off-by: Jessica Frazelle <jess@docker.com> (github: jfrazelle)
Upstream-commit: 664004ed0c6c99369720a00f5673f1e106d9496d
Component: engine
When working with Go channels you must not set it to nil or else the
channel will block forever. It will not panic reading from a nil chan
but it blocks. The correct way to do this is to create the channel then
close it as the correct results to the caller will be returned.
Signed-off-by: Michael Crosby <crosbymichael@gmail.com>
Upstream-commit: 7061a993c5b620d6e68450f1b90f3458bfa1add0
Component: engine
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>
Upstream-commit: 03d3d79b2b3f8b720fff2d649aff0ef791cff417
Component: engine
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>
Upstream-commit: 2c72ff1dbfa83aa8f797bdfebaacb8a919677326
Component: engine
Also cleans up tests to not shell out for file creation.
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
Upstream-commit: 63708dca8a633d68f9342eebd4f7a616e8c48234
Component: engine
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>
Upstream-commit: 584180fce7ad11516a256b8abd4621138337e918
Component: engine
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>
Upstream-commit: 40945fc186067e5b7edd1f6cd7645ff2ae7cea6c
Component: engine
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>
Upstream-commit: d8c628cf082a50c0a2a5e381a21da8279a5462b4
Component: engine
