When xfs filesystem is being used on top of thin pool, xfs can get ENOSPC
errors from thin pool when thin pool is full. As of now xfs retries the
IO and keeps on retrying and does not give up. This can result in container
application being stuck for a very long time. In fact I have seen instances
of unkillable processes. So that means once thin pool is full and process
gets stuck, container can't be stopped/killed either and only option left
seems to be power recycle of the box.
In another instance, writer did not block but failed after a while. But
when I tried to exit/stop the container, unmounting xfs hanged and only
thing I could do was power cycle the machine.
Now upstream kernel has committed patches where it allows user space to
customize user space behavior in case of errors. One of the knobs is
max_retries, which specifies how many times an IO should be retried
when ENOSPC is encountered.
This patch sets provides a tunable knob (dm.xfs_nospace_max_retries) so
that user can specify value for max_retries and tune xfs behavior. If
one sets this value to 0, xfs will not retry IO when ENOSPC error is
encountered. It will instead give up and shutdown filesystem.
This knob can be useful if one is running into unkillable
processes/containers issue on top of xfs.
Signed-off-by: Vivek Goyal <vgoyal@redhat.com>
Upstream-commit: 4f0017b9ad7dfa2e9dcdee69d000b98595893e60
Component: engine
Change related test from DockerSuite to DockerDaemonSuite in `docker_cli_daemon_test.go`
Upstream-commit: b8d510e86ad6a70aad09442b89e0e984b14e0c72
Component: engine
On join, remote addresses are supposed to be detected by the manager
that receives the join request. However, the daemon is interfering with
this by automatically detecting an advertise address and specifying that
to the remote manager. Fix this so that an advertise address is only
specified while joining a cluster if one was given by the user.
Signed-off-by: Aaron Lehmann <aaron.lehmann@docker.com>
Upstream-commit: b1d2b088533187954d3b98ed5951ec2dbbb422e9
Component: engine
We attached the JSON flag to the wrong AST node, causing Docker to treat
the exec form ["binary", "arg"] as if the shell form "binary arg" had
been used. This failed if "ls" was not present.
Added a test to detect this.
Fixes#26174
Signed-off-by: Thomas Leonard <thomas.leonard@docker.com>
Upstream-commit: e95b6b51daed868094c7b66113381d5088e831b4
Component: engine
This adds a `results.xml` to the test-docker-py output folder.
Signed-off-by: Michael Crosby <crosbymichael@gmail.com>
Upstream-commit: a9e513867cd9eb327ae56877886ed18a5ad5b691
Component: engine
Before:
$ docker update --cpu-period
Status: flag needs an argument: --cpu-period
See 'docker update --help'., Code: 125
After:
$ docker update --cpu-period
flag needs an argument: --cpu-period
See 'docker update --help'.
Also remove flagErrorFunc function which isn't needed anymore.
Signed-off-by: Antonio Murdaca <runcom@redhat.com>
Upstream-commit: c2c2617534685917c4a1c2367af861c598cc050a
Component: engine
This fix tries to address the issue raised in comment:
https://github.com/docker/docker/pull/25943#discussion_r76843081
Previously, the validation for `ip6` is done by checking ParseIP().To16().
However, in case an IPv4 address or an IPv4-mapped Ipv6 address has been
provided, the validation will pass (should fail).
This fix first check if `--ip6` is passed with a valid IP address and returns
error for invalid IP addresses. It then check if an IPv4 or IPv4-mapped Ipv6
address is passed, and return error accordingly.
This fix adds two more cases in the tests. One for IPv4 address passed to `--ip6`
and another for Ipv4-mapped IPv6 address passed to `--ip6`. In both cases,
without this fix the validation will pass through.
Signed-off-by: Yong Tang <yong.tang.github@outlook.com>
Upstream-commit: 1e6eccae69bd9b1f65ec87c33a6a872c81f7fb23
Component: engine