If .dockerignore mentions either then the client will send them to the
daemon but the daemon will erase them after the Dockerfile has been parsed
to simulate them never being sent in the first place.
an events test kept failing for me so I tried to fix that too
Closes#8330
Signed-off-by: Doug Davis <dug@us.ibm.com>
Function shouldRestart() checks the restart policy and records the
debug info and there should be two arguments in the log.Debugf().
Prior to the this patch, the logs were something like this:
- client: $ docker run --restart=on-failure:3 ubuntu /bin/sh -c 'exit 1'
- daemon: INFO[0168] ...
DEBU[0168] stopping restart of container %!s(int=3) because maximum
failure could of %!d(MISSING) has been reached
INFO[0086] ...
Btw, fix a spelling error in the same file:
- cotnainer -> container
----------------------------------------
Signed-off-by: Hu Keping <hukeping@huawei.com>
Also makes streamConfig Pipe methods not return error, since there was
no error for them to be able to return anyway.
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
syscall.Unmount failed sometimes when user interrupted exporting,
for example a Ctrl-C, or pipe to commands which closed the pipe early,
like "docker export <container_name> | file -"; this syscall.Unmount
could sometimes return EBUSY and didn't actually umount the filesystem;
which would cause a following export command fail to mount;
change to lazy Unmount with MNT_DETACH can fix the problem, this is
the same behavior as in Shutdown;
```text
time="2015-01-03T21:27:26Z" level=error msg="Warning: error unmounting device
34a3e77cdbca17ceffd0636aee0415bb412996adb12360bfe2585ce30467fa8e: device or resource busy"
```
```
$ docker export thirsty_ardinghelli | file -
/dev/stdin: POSIX tar archive
time="2015-01-03T21:58:17Z" level=fatal msg="write /dev/stdout: broken pipe"
$ docker export thirsty_ardinghelli
time="2015-01-03T21:54:33Z" level=fatal msg="Error: thirsty_ardinghelli: Error getting container
34a3e77cdbca17ceffd0636aee0415bb412996adb12360bfe2585ce30467fa8e from driver devicemapper:
Error mounting '/dev/mapper/docker-253:0-3148372-34a3e77cdbca17ceffd0636aee0415bb412996adb12360bfe2585ce30467fa8e'
on '/var/lib/docker/devicemapper/mnt/34a3e77cdbca17ceffd0636aee0415bb412996adb12360bfe2585ce30467fa8e': device or resource busy"
```
Signed-off-by: Derek Che <drc@yahoo-inc.com>
added exec event log follwing issue #8662 proposal.
logging events for exec create and start API
Signed-off-by: daehyeok mun <daehyeok@daehyeokui-MacBook-Air.local>
This fixes the issue where an lxc.conf override of lxc.network.ipv4 was not being honored.
Docker-DCO-1.1-Signed-off-by: Abin Shahab <ashahab@altiscale.com> (github: ashahab-altiscale)
This commit contains changes for docker:
* user.GetGroupFile to user.GetGroupPath docker/libcontainer#301
* Add systemd support for OOM docker/libcontainer#307
* Support for custom namespaces docker/libcontainer#279, docker/libcontainer#312
* Fixes#9699docker/libcontainer#308
Signed-off-by: Alexander Morozov <lk4d4@docker.com>
This changes the error message that is returned by the daemon when
a container-name already exists.
The old message suggests that containers can be renamed, which is
currently not possible.
To prevent confusion, the part "(or rename)" is removed from
the error-message.
Message before this change;
FATA[0000] Error response from daemon: Conflict, The name foobar is already assigned to 728ac36fb0ab. You have to delete (or rename) that container to be able to assign foobar to a container again.
Message after this change;
FATA[0000] Error response from daemon: Conflict. The name 'foobar' is already in use by container 728ac36fb0ab. You have to delete that container to be able to reuse that name.
Relates to: https://github.com/docker/docker/issues/3036
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
There has been a lot of discussion (issues 4242 and 5262) about making
`FROM scratch` either a special case or making `FROM` optional, implying
starting from an empty file system.
This patch makes the build command `FROM scratch` special cased from now on
and if used does not pull/set the the initial layer of the build to the ancient
image ID (511136ea..) but instead marks the build as having no base image. The
next command in the dockerfile will create an image with a parent image ID of "".
This means every image ever can now use one fewer layer!
This also makes the image name `scratch` a reserved name by the TagStore. You
will not be able to tag an image with this name from now on. If any users
currently have an image tagged as `scratch`, they will still be able to use that
image, but will not be able to tag a new image with that name.
Goodbye '511136ea3c5a64f264b78b5433614aec563103b4d4702f3ba7d4d2698e22c158',
it was nice knowing you.
Fixes#4242
Docker-DCO-1.1-Signed-off-by: Josh Hawn <josh.hawn@docker.com> (github: jlhawn)
To avoid an expensive call to archive.ChangesDirs() which walks two directory
trees and compares every entry, archive.ApplyLayer() has been extended to
also return the size of the layer changes.
Docker-DCO-1.1-Signed-off-by: Josh Hawn <josh.hawn@docker.com> (github: jlhawn)
When we use the engine/env object we can run into a situation where
a string is passed in as the value but later on when we json serialize
the name/value pairs, because the string is made up of just numbers
it appears as an integer and not a string - meaning no quotes. This
can cause parsing issues for clients.
I tried to find all spots where we call env.Set() and the type of the
name being set might end up having a value that could look like an int
(like author). In those cases I switched it to use env.SetJson() instead
because that will wrap it in quotes.
One interesting thing to note about the testcase that I modified is that
the escaped quotes should have been there all along and we were incorrectly
letting it thru. If you look at the metadata stored for that resource you
can see the quotes were escaped and we lost them during the serialization
steps because of the env.Set() stuff. The use of env is probably not the
best way to do all of this.
Closes: #9602
Signed-off-by: Doug Davis <dug@us.ibm.com>
When the user is not using the full has to retrieve a container it's
possible that we find conflicts with the ids of other containers.
At the moment it's just failing saying that it can not find a container,
but it doesn't say why. Adding a small log saying that duplicates where
found is going to help the user.
Closes#8098
Signed-off-by: Alex Gonzalez <agonzalezro@gmail.com>
