Not sure if this is the right setup given the containerd change but I need
to have the built version of the nested exes (containerd, runc...) available
to me after the build is completed so I'm always testing using the latest
versions. This PR will copy them into the same bundles dir so people can
them use them if they wish w/o having to build each separately.
Signed-off-by: Doug Davis <dug@us.ibm.com>
Upstream-commit: 1bf5eb20e53b7e242792fcbe399cb997b6a2ba4b
Component: engine
Add a paragraph about how to force a stack trace dump to the daemon log.
This feature was added in Docker 1.9 I believe, but documentation was
never added.
Docker-DCO-1.1-Signed-off-by: Phil Estes <estesp@linux.vnet.ibm.com> (github: estesp)
Upstream-commit: ae466aafcbd3e000ff9ec2e8bd354fc3cc3729e5
Component: engine
This fix addressed the issue of test TestRestartStoppedContainer
in #21211. Inside the test, a `docker restart` command is
followed by a `docker logs` command. However, `docker restart`
returns immediately so there is no guarantee that `docker logs`
will wait until the restarted container completes the command
`echo foobar`.
This fix use the check of `{{.State.Running}} = false` to make
sure that the restarted container has already finished, before
invoking the `docker logs` command. The timeout is set to 20s
to make sure it passes WindowsTP4 check.
This fixes#21211.
Signed-off-by: Yong Tang <yong.tang.github@outlook.com>
Upstream-commit: 48ccdd46aea4bb16925d0a333f792a712f1c11dc
Component: engine
When following a journal-based log, it was possible for the worker
goroutine, which reads the journal using the journal context and sends
entry data down the message channel, to be scheduled after the function
which started it had returned. This could create problems, since the
invoking function was closing the journal context object and message
channel before it returned, which could trigger use-after-free segfaults
and write-to-closed-channel panics in the worker goroutine.
Make the cleanup in the invoking function conditional so that it's only
done when we're not following the logs, and if we are, that it's left to
the worker goroutine to close them.
Signed-off-by: Nalin Dahyabhai <nalin@redhat.com> (github: nalind)
Upstream-commit: 52c0f36f7b7aa794932fa41dfe50dc85f78e6146
Component: engine
The journald log reader keeps a map of following readers so that it can
close them properly when the journald reader object itself is closed,
but it was possible for its worker goroutine to be scheduled so that the
worker attempted to remove a reader from the map before the reader had
been added to the map. This patch adds the item to the map before
starting the goroutine which is expected to eventually remove it.
Signed-off-by: Nalin Dahyabhai <nalin@redhat.com> (github: nalind)
Upstream-commit: 4d200cd6938c1416e34bf43576b0d528b73e8ba3
Component: engine
This (the first tagged hcsshim release) fixes long-path bugs on
Windows TP5 that affect commit and save. These bugs were blocking
commit of Windows containers that had node.js installed.
Signed-off-by: John Starks <jostarks@microsoft.com>
Upstream-commit: b54058bafe07718a02e81a19b2dfc779dcdf11ba
Component: engine
This pull request fixes several typos in the documentation.
Signed-off-by: Yong Tang <yong.tang.github@outlook.com>
Upstream-commit: 3c6aa163a3fd04c344a2072ab379f0778734b269
Component: engine
All other options we have use `=` as separator, labels,
log configurations, graph configurations and so on.
We should be consistent and use `=` for the security
options too.
Signed-off-by: David Calavera <david.calavera@gmail.com>
Upstream-commit: cb9aeb0413ca75bb3af7fa723a1f2e6b2bdbcb0e
Component: engine
