When the daemon is configured to run with an authorization-plugin and if
the plugin is disabled, the daemon continues to send API requests to the
plugin and expect it to respond. But the plugin has been disabled. As a
result, all API requests are blocked. Fix this behavior by removing the
disabled plugin from the authz middleware chain.
Tested using riyaz/authz-no-volume-plugin and observed that after
disabling the plugin, API request/response is functional.
Fixes#31836
Signed-off-by: Anusha Ragunathan <anusha.ragunathan@docker.com>
Upstream-commit: 38de272bd4dfea945985b7031cd353ac5f6507c5
Component: engine
Fix#31350
As we can see in `daemon.Images()`, there is a gap between
`allImages = daemon.imageStore.Map()` and `l, err :=
daemon.layerStore.Get(layerID)`, so images which still exist when we hit
`allImages = daemon.imageStore.Map()` may have already been deleted when we hit
`l, err := daemon.layerStore.Get(layerID)`.
```
if danglingOnly {
allImages = daemon.imageStore.Heads()
} else {
allImages = daemon.imageStore.Map()
}
...
for id, img := range allImages {
...
layerID := img.RootFS.ChainID()
var size int64
if layerID != "" {
l, err := daemon.layerStore.Get(layerID)
if err != nil {
return nil, err
}
```
Signed-off-by: Yuanhong Peng <pengyuanhong@huawei.com>
Upstream-commit: 2b9694c29e3bbbce23f0c4009f908a23c115c598
Component: engine
This fix tries to address the request in 31325 by adding
`--filter mode=global|replicated` to `docker service ls`.
As `docker service ls` has a `MODE` column by default, it is natural
to support `--filter mode=global|replicated` for `docker service ls`.
There are multiple ways to address the issue. One way is to pass
the filter of mode to SwarmKit, another way is to process the filter
of mode in the daemon.
This fix process the filter in the daemon.
Related docs has been updated.
An integration test has been added.
This fix fixes 31325.
Signed-off-by: Yong Tang <yong.tang.github@outlook.com>
Upstream-commit: 43a1bd564b5dbd835631cda102f68286c0d533e9
Component: engine
When 567ef8e7858c ("daemon: switch to 'ensure' workflow for AppArmor
profiles") was merged, it didn't correctly handle the exec path if
AppArmor profiles were deleted. Fix this by duplicating the
ensureDefaultApparmorProfile code in the exec code.
Fixes: 567ef8e7858c ("daemon: switch to 'ensure' workflow for AppArmor profiles")
Signed-off-by: Aleksa Sarai <asarai@suse.de>
Upstream-commit: 790a81ea9acce318d0e037771c253951b874140b
Component: engine
This change adds the ability to do --tail and --since on docker service
logs. It wires up the API endpoints to each other and fixes some older
bugs. It adds integration tests for these new features.
Signed-off-by: Drew Erny <drew.erny@docker.com>
Upstream-commit: 8dc437bd9b474c24a2cf802c2779dace2f91194a
Component: engine
Right now getting logs from a service with an attached TTY does not
work. The behavior was undefined and caused the command to hang and
strange messages to occur in the daemon logs.
This returns errors, both deep in the swarmkit adapter (to guard against
undefined behavior, which is Bad) and in the daemon (to tell users that
the thing they're asking for is not possible).
Signed-off-by: Drew Erny <drew.erny@docker.com>
Upstream-commit: 37ae1ef0ffcf8605daeaf41440da774370377a6d
Component: engine
In https://github.com/torvalds/linux/commit/5ca3726 (released in v4.7-rc1) the
content of the `cpuacct.usage_percpu` file in sysfs was changed to include both
online and offline cpus. This broke the arithmetic in the stats helpers used by
`docker stats`, since it was using the length of the PerCPUUsage array as a
proxy for the number of online CPUs.
Add current number of online CPUs to types.StatsJSON and use it in the
calculation.
Keep a fallback to `len(v.CPUStats.CPUUsage.PercpuUsage)` so this code
continues to work when talking to an older daemon. An old client talking to a
new daemon will ignore the new field and behave as before.
Fixes#28941.
Signed-off-by: Ian Campbell <ian.campbell@docker.com>
Upstream-commit: 115f91d7575d6de6c7781a96a082f144fd17e400
Component: engine
The response would never reach the client because it was being
redeclared in the current scope.
Signed-off-by: Aaron Lehmann <aaron.lehmann@docker.com>
Upstream-commit: 9d127f8de3fa489b2c0d896dd9612f43e45f7cdd
Component: engine
Running the rm command on a paused/restarting container
will give an error message saying the container is running
which is incorrect.
To fix that, the error message will have the correct
container state and a procedure to remove it accordingly.
Notice: docker-py was bumped to:
4a08d04aef0595322e1b5ac7c52f28a931da85a5
Signed-off-by: Boaz Shuster <ripcurld.github@gmail.com>
Upstream-commit: 0ec8f56a3d7f1413cdb3ae7711d518e99f9282e9
Component: engine
Since it was introduced no reports were made and lsof seems to cause
issues on some systems.
Signed-off-by: Kenfe-Mickael Laventure <mickael.laventure@gmail.com>
Upstream-commit: eac66b67be0710322d0e21a67a55f5731be48f68
Component: engine
The current behavior is for dockerd to fail to start if the swarm
component can't be started for some reason. This can be difficult to
debug remotely because the daemon won't be running at all, so it's not
possible to hit endpoints like /info to see what's going on. It's also
very difficult to recover from the situation, since commands like
"docker swarm leave" are unavailable.
Change the behavior to allow startup to proceed.
Signed-off-by: Aaron Lehmann <aaron.lehmann@docker.com>
Upstream-commit: f7d846094a5dc642198cc4939df646a3e889a750
Component: engine
When pinning by digest, the registry might be slow or unresponsive. This
could cause the context to already be expired by the time UpdateService
or CreateService is called. We want digest pinning to be a best-effort
operation, so it's problematic if a slow or misbehaving registry
prevents the service operation from completing. Replace the context
after communicating with the registry, so we have a fresh timeout for
the gRPC call.
Signed-off-by: Aaron Lehmann <aaron.lehmann@docker.com>
Upstream-commit: f8273a216ed35e22ac157dee8055393f07d4be39
Component: engine
Server-side rollback can take advantage of the rollback-specific update
parameters, instead of being treated as a normal update that happens to
go back to a previous version of the spec.
Signed-off-by: Aaron Lehmann <aaron.lehmann@docker.com>
Upstream-commit: f9bd8ec8b268581f93095c5a80679f0a8ff498bf
Component: engine
--max-concurrent-downloads,--max-concurrent-uploads must great than or equal to 0
Upstream-commit: dc1b0e1b2c8483e0f2eaa28316be01aae6d6ae4a
Component: engine
