Permalink
Commits on Oct 23, 2018
-
Description: When docker is in startup process and containerd sends an "process exit" event to docker. If the container config '--restart=always', restartmanager will start this container very soon. But some initialization is not done, e.g. `daemon.netController`,when visit, docker would panic. Signed-off-by: Wentao Zhang <zhangwentao234@huawei.com>
-
committed
Oct 22, 2018 Upstream already behaves this way and it isn't merely an aesthetic change. Doing this fixes an issue where count can become -1 when a new daemon instance attempts to unmount the container base dir, with the later not being actually mounted. The most common action leading to this scenario is an unorderly restart of the server running docker. After count becomes -1, a combination of "docker start" + "docker restart" will lead to a situation in which the mountpoint is not visible from the global namespace, and attempts to run new processes in the container will fail with an error like this one: error: code = 2 desc = oci runtime error: exec failed: container_linux.go:247: starting container process caused "process_linux.go:75: starting setns process caused \"fork/exec /proc/self/exe: no such file or directory\"" Signed-off-by: Sergio Lopez <slp@redhat.com>
Commits on Oct 20, 2018
-
reference.store.addReference fails when adding a digest reference that already exists (regardless of the reference target). Both callers (via reference.store.AddDigest) do check in advance, using reference.store.Get, whether the digest reference exists before calling AddDigest, but the reference store lock is released between the two calls, so if another thread sets the reference in the meantime, AddDigest may fail with > Cannot overwrite digest ... . Handle this by checking that the pre-existing reference points at the same image, i.e. that there is nothing to do, and succeeding immediately in that case. This is even cheaper, avoids a reference.store.save() call. (In principle, the same failure could have happened via reference.store.AddTag, as > Conflict: Tag %s is already set to image %s, if you want to replace it, please use -f option but almost all callers (except for migrate/v1.Migrate, which is run single-threaded anyway) set the "force" parameter of AddTag to true, which makes the race invisible. This commit does not change the behavior of that case, except for speeding it up by avoiding the reference.store.save() call.) The existing reference.store.Get checks are now, in a sense, redundant as such, but their existence allows the callers to provide nice context-dependent error messages, so this commit leaves them unchanged. Signed-off-by: Miloslav Trmač <mitr@redhat.com>
Commits on Oct 17, 2018
-
Upstream PR: docker/libnetwork#1778 Signed-off-by: Shijiang Wei <mountkin@gmail.com>
-
Upstream PR: docker/libnetwork#1700 Signed-off-by: Shijiang Wei <mountkin@gmail.com>
Commits on Oct 13, 2018
Commits on Oct 12, 2018
Commits on Oct 11, 2018
Commits on Oct 10, 2018
-
This leaks information about keyrings on the host. Keyrings are not namespaced. Signed-off-by: Justin Cormack <justin.cormack@docker.com>
Commits on Oct 8, 2018
-
runcom committed
Oct 8, 2018 https://bugzilla.redhat.com/show_bug.cgi?id=1636259 Signed-off-by: Antonio Murdaca <runcom@redhat.com>
Commits on Sep 6, 2018
Commits on Sep 4, 2018
Commits on Aug 27, 2018
-
When the authz response buffer limit is hit, perform a flush. This prevents excessive buffer sizes, especially on large responses (e.g. `/containers/<id>/archive` or `/containers/<id>/export`). Signed-off-by: Brian Goff <cpuguy83@gmail.com>
Commits on Aug 9, 2018
Commits on Aug 1, 2018
-
runcom committed
Aug 1, 2018 …refix-1.13.1-rhel volume: skip resolving symlinks without a prefix
Commits on Jul 30, 2018
-
drops a part of 38e1b7d, so that the behavior doesn't change when the new feature is not used. Closes: https://bugzilla.redhat.com/show_bug.cgi?id=1603201 Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
Commits on Jul 6, 2018
Commits on Jun 26, 2018
Commits on Jun 25, 2018
Commits on Jun 21, 2018
-
runcom committed
Jun 21, 2018 Fix BZ https://bugzilla.redhat.com/show_bug.cgi?id=1563650 Signed-off-by: Antonio Murdaca <runcom@redhat.com>
Commits on Jun 11, 2018
-
runcom committed
Jun 11, 2018 Signed-off-by: Jim Minter <jminter@redhat.com> Signed-off-by: Antonio Murdaca <runcom@redhat.com>
-
Before this patch, a log reader is able to block all log writes indefinitely (and other operations) by simply opening the log stream and not consuming all the messages. The reason for this is we protect the read stream from corruption by ensuring there are no new writes while the log stream is consumed (and caught up with the live entries). We can get around this issue because log files are append only, so we can limit reads to only the section of the file that was written to when the log stream was first requested. Now logs are only blocked until all files are opened, rather than streamed to the client. Signed-off-by: Brian Goff <cpuguy83@gmail.com>
-
Signed-off-by: Jim Minter <jminter@redhat.com>
-
This reduces allocs and bytes used per log entry significantly as well as some improvement to time per log operation. Each log driver, however, must put messages back in the pool once they are finished with the message. Signed-off-by: Brian Goff <cpuguy83@gmail.com>
-
Signed-off-by: Akihiro Suda <suda.akihiro@lab.ntt.co.jp>
-
This allows the user to set a logging mode to "blocking" (default), or "non-blocking", which uses the ring buffer as a proxy to the real log driver. This allows a container to never be blocked on stdio at the cost of dropping log messages. Introduces 2 new log-opts that works for all drivers, `log-mode` and `log-size`. `log-mode` takes a value of "blocking", or "non-blocking" I chose not to implement this as a bool since it is difficult to determine if the mode was set to false vs just not set... especially difficult when merging the default daemon config with the container config. `log-size` takes a size string, e.g. `2MB`, which sets the max size of the ring buffer. When the max size is reached, it will start dropping log messages. ``` BenchmarkRingLoggerThroughputNoReceiver-8 2000000000 36.2 ns/op 856.35 MB/s 0 B/op 0 allocs/op BenchmarkRingLoggerThroughputWithReceiverDelay0-8 300000000 156 ns/op 198.48 MB/s 32 B/op 0 allocs/op BenchmarkRingLoggerThroughputConsumeDelay1-8 2000000000 36.1 ns/op 857.80 MB/s 0 B/op 0 allocs/op BenchmarkRingLoggerThroughputConsumeDelay10-8 1000000000 36.2 ns/op 856.53 MB/s 0 B/op 0 allocs/op BenchmarkRingLoggerThroughputConsumeDelay50-8 2000000000 34.7 ns/op 894.65 MB/s 0 B/op 0 allocs/op BenchmarkRingLoggerThroughputConsumeDelay100-8 2000000000 35.1 ns/op 883.91 MB/s 0 B/op 0 allocs/op BenchmarkRingLoggerThroughputConsumeDelay300-8 1000000000 35.9 ns/op 863.90 MB/s 0 B/op 0 allocs/op BenchmarkRingLoggerThroughputConsumeDelay500-8 2000000000 35.8 ns/op 866.88 MB/s 0 B/op 0 allocs/op ``` Signed-off-by: Brian Goff <cpuguy83@gmail.com>
-
Signed-off-by: Yanqiang Miao <miao.yanqiang@zte.com.cn> update Signed-off-by: Yanqiang Miao <miao.yanqiang@zte.com.cn>
NewerOlder