Currently if we exec a restarting container, client will fail silently,
and daemon will print error that container can't be found which is not a
very meaningful prompt to user.
This commit will stop user from exec a restarting container and gives
more explicit error message.
Signed-off-by: Zhang Wei <zhangwei555@huawei.com>
Upstream-commit: 1d2208fed90da9ab72ded3b1c65bb2a71b66ce93
Component: engine
Issue was caused when exec is tarted, exits, then stated again.
In this case, `Close` is called twice, which closes a channel twice.
Changes execConfig.ExitCode to a pointer so we can test if the it has
been set or not.
This allows us to return early when the exec has already been run.
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
Upstream-commit: 1a60a805bfabee729dbc833515cd0be439adb95b
Component: engine
Implement configurable detach keys (for `attach`, exec`, `run` and
`start`) using the client-side configuration
- Adds a `--detach-keys` flag to `attach`, `exec`, `run` and `start`
commands.
- Adds a new configuration field (in `~/.docker/config.json`) to
configure the default escape keys for docker client.
Signed-off-by: Vincent Demeester <vincent@sbr.pm>
Upstream-commit: 15aa2a663b47b6126a66efefcadb64edfbffb9f5
Component: engine
This is a very docker concept that nobody elses need.
We only maintain it to keep the API backwards compatible.
Signed-off-by: David Calavera <david.calavera@gmail.com>
Upstream-commit: f9b857a200696b07b67e6a7f94ede32487f5649d
Component: engine
This is more aligned with `Daemon.GetImage` and less confusing.
Signed-off-by: David Calavera <david.calavera@gmail.com>
Upstream-commit: d7d512bb927023b76c3c01f54a3655ee7c341637
Component: engine
So other packages don't need to import the daemon package when they
want to use this struct.
Signed-off-by: David Calavera <david.calavera@gmail.com>
Signed-off-by: Tibor Vass <tibor@docker.com>
Upstream-commit: 6bb0d1816acd8d4f7a542a6aac047da2b874f476
Component: engine
Remove double reference between containers and exec configurations by
keeping only the container id.
Signed-off-by: David Calavera <david.calavera@gmail.com>
Upstream-commit: 9ca2e4e81cdb950f2b5958a7712153d1a6dd6e4c
Component: engine
This is a small configuration struct used in two scenarios:
1. To attach I/O pipes to a running containers.
2. To attach to execution processes inside running containers.
Although they are similar, keeping the struct in the same package
than exec and container can generate cycled dependencies if we
move any of them outside the daemon, like we want to do
with the container.
Signed-off-by: David Calavera <david.calavera@gmail.com>
Upstream-commit: 3f5b8f712d693188b41b3d9b55e5e5213be48ef5
Component: engine
The LXC driver was deprecated in Docker 1.8.
Following the deprecation rules, we can remove a deprecated feature
after two major releases. LXC won't be supported anymore starting on Docker 1.10.
Signed-off-by: David Calavera <david.calavera@gmail.com>
Upstream-commit: 3b5fac462d21ca164b3778647420016315289034
Component: engine
Create a supervisor interface to let the container monitor to emit events.
Signed-off-by: David Calavera <david.calavera@gmail.com>
Upstream-commit: ca5ede2d0a23cb84cac3b863c363d0269e6438df
Component: engine
progressreader.Broadcaster becomes broadcaster.Buffered and
broadcastwriter.Writer becomes broadcaster.Unbuffered.
The package broadcastwriter is thus renamed to broadcaster.
Signed-off-by: Tibor Vass <tibor@docker.com>
Upstream-commit: 2391233404e2e6892c79a24f31cc99715c086b21
Component: engine
Exec start was sending HTTP 500 for every error.
Fixed an error where pausing a container and then calling exec start
caused the daemon to freeze.
Updated API docs which incorrectly showed that a successful exec start
was an HTTP 201, in reality it is HTTP 200.
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
Upstream-commit: 2d43d93410c29cec87deb9cd940c3b2a8af5fbbb
Component: engine
Although having a request ID available throughout the codebase is very
valuable, the impact of requiring a Context as an argument to every
function in the codepath of an API request, is too significant and was
not properly understood at the time of the review.
Furthermore, mixing API-layer code with non-API-layer code makes the
latter usable only by API-layer code (one that has a notion of Context).
This reverts commit de4164043546d2b9ee3bf323dbc41f4979c84480, reversing
changes made to 7daeecd42d7bb112bfe01532c8c9a962bb0c7967.
Signed-off-by: Tibor Vass <tibor@docker.com>
Conflicts:
api/server/container.go
builder/internals.go
daemon/container_unix.go
daemon/create.go
Upstream-commit: b08f071e18043abe8ce15f56826d38dd26bedb78
Component: engine
This PR adds a "request ID" to each event generated, the 'docker events'
stream now looks like this:
```
2015-09-10T15:02:50.000000000-07:00 [reqid: c01e3534ddca] de7c5d4ca927253cf4e978ee9c4545161e406e9b5a14617efb52c658b249174a: (from ubuntu) create
```
Note the `[reqID: c01e3534ddca]` part, that's new.
Each HTTP request will generate its own unique ID. So, if you do a
`docker build` you'll see a series of events all with the same reqID.
This allow for log processing tools to determine which events are all related
to the same http request.
I didn't propigate the context to all possible funcs in the daemon,
I decided to just do the ones that needed it in order to get the reqID
into the events. I'd like to have people review this direction first, and
if we're ok with it then I'll make sure we're consistent about when
we pass around the context - IOW, make sure that all funcs at the same level
have a context passed in even if they don't call the log funcs - this will
ensure we're consistent w/o passing it around for all calls unnecessarily.
ping @icecrime @calavera @crosbymichael
Signed-off-by: Doug Davis <dug@us.ibm.com>
Upstream-commit: 26b1064967d9fcefd4c35f60e96bf6d7c9a3b5f8
Component: engine
Using @mavenugo's patch for enabling the libcontainer pre-start hook to
be used for network namespace initialization (correcting the conflict
with user namespaces); updated the boolean check to the more generic
SupportsHooks() name, and fixed the hook state function signature.
Signed-off-by: Madhu Venugopal <madhu@docker.com>
Docker-DCO-1.1-Signed-off-by: Phil Estes <estesp@linux.vnet.ibm.com> (github: estesp)
Upstream-commit: e148e763b8e7879855022690fdea88a6bf869195
Component: engine
- some method names were changed to have a 'Locking' suffix, as the
downcased versions already existed, and the existing functions simply
had locks around the already downcased version.
- deleting unused functions
- package comment
- magic numbers replaced by golang constants
- comments all over
Signed-off-by: Morgan Bauer <mbauer@us.ibm.com>
Upstream-commit: abd72d4008dde7ee8249170d49eb4bc963c51e24
Component: engine
This reverts commit 40b71adee390e9c06471b89ed845132b4ec80177.
Original commit (for which this is effectively a rebased version) is
72a500e9e5929b038816d8bd18d462a19e571c99 and was provided by Lei Jitang
<leijitang@huawei.com>.
Signed-off-by: Tim Dettrick <t.dettrick@uq.edu.au>
Upstream-commit: 03f65b3d0d66ccdc8b69a447b75508d594007600
Component: engine
Also cleans up some of the API side of exec.
Was writing the header twice (two different headers).
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
Upstream-commit: f078f75bf25353720f28f9f1ea180374fe205302
Component: engine
This allow us to avoid entropy usage in non-crypto critical places.
Signed-off-by: Alexander Morozov <lk4d4@docker.com>
Upstream-commit: 6bca8ec3c9ccc169c53b3d7060fe5c8ba8670aac
Component: engine
When a container is removed but it had an exec, that still hasn't been
GC'd per PR #14476, and someone tries to inspect the exec we should
return a 404, not a 500+container not running. Returning "..not running" is
not only misleading because it could lead people to think the container is
actually still around, but after 5 minutes the error will change to a 404
after the GC. This means that we're externalizing our internall soft-deletion/GC
logic which shouldn't be any of the end user's concern. They should get the
same results immediate or after 5 minutes.
Signed-off-by: Doug Davis <dug@us.ibm.com>
Upstream-commit: d841b779fda882c3fd505f626c01cc9d60768aa6
Component: engine
This takes the final removal for exec commands in two steps. The first
GC tick will mark the exec commands for removal and then the second tick
will remove the config from the daemon.
Signed-off-by: Michael Crosby <crosbymichael@gmail.com>
Upstream-commit: 34ab8c432691934745d66ee94ff4aec1120518e0
Component: engine
This adds an event loop for running a GC cleanup for exec command
references that are on the daemon. These cannot be cleaned up
immediately because processes may need to get the exit status of the
exec command but it should not grow out of bounds. The loop is set to a
default 5 minute interval to perform cleanup.
It should be safe to perform this cleanup because unless the clients are
remembering the exec id of the process they launched they can query for
the status and see that it has exited. If they don't save the exec id
they will have to do an inspect on the container for all exec instances
and anything that is not live inside that container will not be returned
in the container inspect.
Signed-off-by: Michael Crosby <crosbymichael@gmail.com>
Upstream-commit: 5f017bba48e5c763157e1b35a5edea64cc41fc6a
Component: engine
This removes the exec config from the container after the command exits
so that dead exec commands are not displayed in the container inspect.
The commands are still kept on the daemon so that when you inspect the
exec command, not the container, you are still able to get it's exit
status.
This also changes the ProcessConfig to a pointer.
Signed-off-by: Michael Crosby <crosbymichael@gmail.com>
Upstream-commit: 04c9f86bdcf9f42deb09df76922a8c61205721a2
Component: engine
Move some calls to container.LogEvent down lower so that there's
less of a chance of them being missed. Also add a few more events
that appear to have been missed.
Added testcases for new events: commit, copy, resize, attach, rename, top
Signed-off-by: Doug Davis <dug@us.ibm.com>
Upstream-commit: 8232312c1e705753d3db82dca3d9bb23e59c3b52
Component: engine
Also removed the function ExecConfigFromJob
Signed-off-by: Sun Jianbo <wonderflow@zju.edu.cn>
Signed-off-by: Alexander Morozov <lk4d4@docker.com>
Upstream-commit: 24425021d26f29a475702064181e6c99fb6bd1c5
Component: engine
