Currently if you restart docker daemon, all the containers with restart
policy `on-failure` regardless of its `RestartCount` will be started,
this will make daemon cost more extra time for restart.
This commit will stop these containers to do unnecessary start on
daemon's restart.
Signed-off-by: Zhang Wei <zhangwei555@huawei.com>
Upstream-commit: 51e42e6ee01eb4b5c8c7678e2fc7be0f13ef6a68
Component: engine
Fix incorrect request json body for `/containers/create` in remote API docs.
Upstream-commit: 0f904dc2561e7d5c4a0a9435610132e94de377a1
Component: engine
This fix tries to fix the issue in #21848 where `docker stats` will not correctly
display the container stats in case the container reuse another container's
network stack.
The issue is that when `stats` is performed, the daemon will check for container
network setting's `SandboxID`. Unfortunately, for containers that reuse another
container's network stack (`NetworkMode.IsConnected()`), SandboxID is not assigned.
Therefore, the daemon thinks the id is invalid and remote API will never return.
This fix tries to resolve the SandboxID by iterating through connected containers
and identify the appropriate SandboxID.
A test case for `stats` remote API has been added to check if `stats` will return
within the timeout.
This fix fixes#21848.
Signed-off-by: Yong Tang <yong.tang.github@outlook.com>
Upstream-commit: faf2b6f7aaca7f9ef400e227921b8125590fc9e5
Component: engine
This fix tries to fix the incorrect request json body for
`/containers/create` in remote API docs.
When using the example json request for `/containers/create`, there are two
errors:
(1). `invalid character '"' after object key:value pair`
This is because a `,` is missing after `"Volumes": {}`
This issue exists in v1.20-v1.24
(2). `Invalid --security-opt: ""`
This is becasue in `"SecurityOpt": [""]` line, an empty string
`""` is passed yet `""` is not a valid `SecurityOpt`. Either no string,
or a valid string (e.g., "no-new-privileges") could be used.
This issue exists in v1.15-v1.24
This fix updates the docs and correct the above two issues.
Signed-off-by: Yong Tang <yong.tang.github@outlook.com>
Upstream-commit: f919a26a9fb96ef07133183b4f693ff9508ae823
Component: engine
Now that we are checking if the image and host have the same architectures
via #21272, this value should be null so that the test passes on non-x86
machines
Signed-off-by: Christopher Jones <tophj@linux.vnet.ibm.com>
Upstream-commit: 1f59bc8c03df18686b93a0cd619cf2c55cbcf421
Component: engine
This fix tries to fix the discrepancy between `docker stats` and
`docker run` where `docker run` uses RAMInBytes for all memory
related inputs but `docker stats` uses HumanSize for all memory
related outputs.
To be consistent, `docker stats` needs to use BytesSize for all
memory related outputs to conform to RAMInBytes in `docker run`.
This fix addresses this issue. As BytesSize is used, the test
cases needs to be adjusted to match `KiB/MiB/GiB` instead of
`KB/MB/GB`.
The documentation has also been updated.
This fix fixes#21765.
Signed-off-by: Yong Tang <yong.tang.github@outlook.com>
Upstream-commit: 0e3846e280195cb47c47a7739b475b281dd301cb
Component: engine
When user try to restart a restarting container, docker client report
error: "container is already active", and container will be stopped
instead be restarted which is seriously wrong.
What's more critical is that when user try to start this container
again, it will always fail.
This error can also be reproduced with a `docker stop`+`docker start`.
And this commit will fix the bug.
Signed-off-by: Zhang Wei <zhangwei555@huawei.com>
Upstream-commit: a705e166cf3bcca62543150c2b3f9bfeae45ecfa
Component: engine
This fix tries to fix the discrepancy between API and CLI on hostname
validation. Previously, the hostname validation was handled at the
CLI interface in runconfig/opts/parse.go and return an error if the
hostname is invalid. However, if an end user use the remote API to
pass the hostname, the error will not be returned immediately.
Instead the error will only be thrown out when the container creation
fails. This creates behavior discrepancy between API and CLI.
In this fix, the hostname validation was moved to
verifyContainerSettings so the behavior will be the same for API and
CLI.
After the change, since CLI does not handle the hostname validation
any more, the previous unit tests about hostname validation on CLI
in runconfig/opts/parse_test.go has to be updated as well because
there is no validation at this stage. All those unit tests are moved
to integration test TestRunTooLongHostname so that the hostname
validation is still properly covered as before.
Note: Since the hostname validation moved to API, the error message
changes from `invalid hostname format for --hostname:` to
`invalid hostname format:` as well because `--hostname` is passed
to CLI only.
This fix fixes#21595.
Signed-off-by: Yong Tang <yong.tang.github@outlook.com>
Upstream-commit: ee4bd806ba6ccac0013eb812e7f30bfcfe12d22a
Component: engine
This fix tries to add an additional syslog-format of `rfc5424micro` which follows
the same as rfc5424 except that it use microsecond resolution for timestamp. The
purpose is to solve the issue raised in #21793 where log events might lose its
ordering if happens on the same second.
The timestamp field in rfc5424 is derived from rfc3339, though the maximium
resolution is limited to "TIME-SECFRAC" which is 6 (microsecond resolution).
The appropriate documentation (`docs/admin/logging/overview.md`) has been updated
to reflect the change in this fix.
This fix adds a unit test to cover the newly introduced format.
This fix fixes#21793.
Signed-off-by: Yong Tang <yong.tang.github@outlook.com>
Upstream-commit: 7581cf96fbe0cddacf246f2982634190ebe455c9
Component: engine
When container is automatically restarted based on restart policy,
docker events can't get "start" event but only get "die" event, this is
not consistent with previous behavior. This commit will add "start"
event back.
Signed-off-by: Zhang Wei <zhangwei555@huawei.com>
Upstream-commit: fdfaaeb9aa72404bde5207510bf5910893414b5d
Component: engine