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
We should be assigning value to minFreeMetadata instead of minFreeData. This
is copy/paste error.
Signed-off-by: Vivek Goyal <vgoyal@redhat.com>
Upstream-commit: 4141a00921e3ae814736249ec1806d5d35c8d46c
Component: engine
The GCP logging driver is calling out to GCP cloud service on package
init.
This is regardless if you are using GCP logging or not.
This change makes this happen on the first invocation of a new GCP
logging driver instance instead.
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
Upstream-commit: 24710fd3e228398dc02c72ab3f0efe70d70c313e
Component: engine
-Temporary until we find the source of CI/v6 issue with driver
Signed-off-by: Brent Salisbury <brent@docker.com>
Upstream-commit: 6d43dc99e5e67210ca502ec2eca12ae1ee9c2600
Component: engine
Missing documentation and man pages on seccomp options.
Signed-off-by: Dan Walsh <dwalsh@redhat.com>
Upstream-commit: 450fa7536edc03fb5b071c0d04af534b2f8572ff
Component: engine
The issue of the flaky test is because when the second container
starts, the first container in the detached mode may have only
been created and not yet entering the running state. So the
port 8000 might be used by the second container first.
This fix added a check to make sure the first container is already
in running state, before the second container is invoked.
This fix fixes#21247.
Signed-off-by: Yong Tang <yong.tang.github@outlook.com>
Upstream-commit: 1a9f5f4c69451c580595d67844f41937b3293069
Component: engine