Treat return code -1 as error instead.
People from glibc say that errno is undefined in case of successful
sysconf call according to POSIX standard:
Glibc bug: https://sourceware.org/bugzilla/show_bug.cgi?id=21536
More over in sysconf man it is wrongly said that "errno is not changed"
on success. So I've created a bug to man-pages:
https://bugzilla.kernel.org/show_bug.cgi?id=195955
Background: Glibc's sysconf(_SC_NPROCESSORS_ONLN) changes errno to
ENOENT, if there is no /sys/devices/system/cpu/online file, while
the call itself is successful. In Virtuozzo containers we prohibit
most of sysfs files for security reasons. So we have Run():daemon
/stats/collector.go infinitely loop never actualy collecting stats
from publisher pairs.
v2: add comment
Signed-off-by: Pavel Tikhomirov <ptikhomirov@virtuozzo.com>
Upstream-commit: dec084962eab41eb20b1808955de34cfec4fc8b3
Component: engine
This makes integration not depend anymore of `cli` and thus not
require `cobra` and other packages to compile.
Signed-off-by: Vincent Demeester <vincent@sbr.pm>
Upstream-commit: 71d60ec0eb7eeddc73d2cf63748ab7debe3f06af
Component: engine
This was mistakenly unmounting everything under `plugins/*` instead of
just `plugins/<id>/*` anytime a plugin is removed.
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
Upstream-commit: db5f31732a9868c1e9e4f9a49be70b794ff82d4f
Component: engine
It has observed defunct containerd processes accumulating over
time while dockerd was permanently failing to restart containerd.
Due to a bug in the runContainerdDaemon() function, dockerd does not clean up
its child process if containerd already exits very soon after the (re)start.
The reproducer and analysis below comes from docker 1.12.x but bug
still applies on latest master.
- from libcontainerd/remote_linux.go:
329 func (r *remote) runContainerdDaemon() error {
:
: // start the containerd child process
:
403 if err := cmd.Start(); err != nil {
404 return err
405 }
:
: // If containerd exits very soon after (re)start, it is
possible
: // that containerd is already in defunct state at the time
when
: // dockerd gets here. The setOOMScore() function tries to
write
: // to /proc/PID_OF_CONTAINERD/oom_score_adj. However, this
fails
: // with errno EINVAL because containerd is defunct. Please see
: // snippets of kernel source code and further explanation
below.
:
407 if err := setOOMScore(cmd.Process.Pid, r.oomScore); err != nil
{
408 utils.KillProcess(cmd.Process.Pid)
:
: // Due to the error from write() we return here. As
the
: // goroutine that would clean up the child has not
been
: // started yet, containerd remains in the defunct
state
: // and never gets reaped.
:
409 return err
410 }
:
417 go func() {
418 cmd.Wait()
419 close(r.daemonWaitCh)
420 }() // Reap our child when needed
:
423 }
This is the kernel function that gets invoked when dockerd tries to
write
to /proc/PID_OF_CONTAINERD/oom_score_adj.
- from fs/proc/base.c:
1197 static ssize_t oom_score_adj_write(struct file *file, ...
1198 size_t count, loff_t
*ppos)
1199 {
:
1223 task = get_proc_task(file_inode(file));
:
: // The defunct containerd process does not have a virtual
: // address space anymore, i.e. task->mm is NULL. Thus the
: // following code returns errno EINVAL to dockerd.
:
1230 if (!task->mm) {
1231 err = -EINVAL;
1232 goto err_task_lock;
1233 }
:
1253 err_task_lock:
:
1257 return err < 0 ? err : count;
1258 }
The purpose of the following program is to demonstrate the behavior of
the oom_score_adj_write() function in connection with a defunct process.
$ cat defunct_test.c
\#include <unistd.h>
main()
{
pid_t pid = fork();
if (pid == 0)
// child
_exit(0);
// parent
pause();
}
$ make defunct_test
cc defunct_test.c -o defunct_test
$ ./defunct_test &
[1] 3142
$ ps -f | grep defunct_test | grep -v grep
root 3142 2956 0 13:04 pts/0 00:00:00 ./defunct_test
root 3143 3142 0 13:04 pts/0 00:00:00 [defunct_test] <defunct>
$ echo "ps 3143" | crash -s
PID PPID CPU TASK ST %MEM VSZ RSS COMM
3143 3142 2 ffff880035def300 ZO 0.0 0 0
defunct_test
$ echo "px ((struct task_struct *)0xffff880035def300)->mm" | crash -s
$1 = (struct mm_struct *) 0x0
^^^ task->mm is NULL
$ cat /proc/3143/oom_score_adj
0
$ echo 0 > /proc/3143/oom_score_adj
-bash: echo: write error: Invalid argument"
---
This patch fixes the above issue by making sure we start the reaper
goroutine as soon as possible.
Signed-off-by: Antonio Murdaca <runcom@redhat.com>
Upstream-commit: 27087eacbf96e6ef9d48a6d3dc89c7c1cff155b4
Component: engine
Closes#32663 by adding CreatedAt field when volume is created.
Displaying CreatedAt value when volume is inspected
Adding tests to verfiy the new field is correctly populated
Signed-off-by: Marianna <mtesselh@gmail.com>
Moving CreatedAt tests from the CLI
Moving the tests added for the newly added CreatedAt field for Volume, from CLI to API tests
Signed-off-by: Marianna <mtesselh@gmail.com>
Upstream-commit: a46f757c4043031379362c5d6b3bad7562ab9fed
Component: engine
DeviceMapper tasks in go use SetFinalizer to clean up C construct
counterparts in the C LVM library. While thats well and good, it relies
heavily on the exact interpretation of when the golang garbage collector
determines that an object is unreachable is subject to reclaimation.
While common sense would assert that for stack variables (which these DM
tasks always are), are unreachable when the stack frame in which they
are declared returns, thats not the case. According to this:
https://golang.org/pkg/runtime/#SetFinalizer
The garbage collector decides that, if a function calls into a
systemcall (which task.run() always will in LVM), and there are no
subsequent references to the task variable within that stack frame, then
it can be reclaimed. Those conditions are met in several devmapper.go
routines, and if the garbage collector runs in the middle of a
deviceMapper operation, then the task can be destroyed while the
operation is in progress, leading to crashes, failed operations and
other unpredictable behavior.
The fix is to use the KeepAlive interface:
https://golang.org/pkg/runtime/#KeepAlive
The KeepAlive method is effectively an empy reference that fools the
garbage collector into thinking that a variable is still reachable. By
adding a call to KeepAlive in the task.run() method, we can ensure that
the garbage collector won't reclaim a task object until its execution
within the deviceMapper C library is complete.
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
Upstream-commit: d764d8b16624e4924b3949273089f851efa0f717
Component: engine
We should check for error before reading the response (response can be
nil, and thus this would panic)
Signed-off-by: Vincent Demeester <vincent@sbr.pm>
Upstream-commit: 45e0376ea361811b2f5d0653a6b103dd39653371
Component: engine
Extract a common function for builder.createContainer
Extract imageCache for doing cache probes
Removes the cacheBuested field from Builder
Create a new containerManager class which reduces the interface between the
builder and managing containers to 3 functions (from 6)
Signed-off-by: Daniel Nephin <dnephin@docker.com>
Upstream-commit: 19f3b0715cf89f336efa286ea1d3f8b57d8c4973
Component: engine
However, do clear the directory if init or join fails, because we don't
want to leave it in a half-finished state.
Signed-off-by: Ying Li <ying.li@docker.com>
Upstream-commit: bf3e9293a66c77a2fddf4e691222898846b4af9f
Component: engine
This appears to be a remnant from the CLI that is no longer imported
anywhere. Remove it from vendor.conf and the vendor directory.
Signed-off-by: Aaron Lehmann <aaron.lehmann@docker.com>
Upstream-commit: aa6fc939baf0bae00391a0ba703187018055b8bf
Component: engine
This commit exposes `Client.host` as `Client.DaemonHost()`
This allows users of the client, a CLI for example, to query the Host
that the client is attempting to contact and vary their behaviour
accordingly. For example, to allow client-side configuration of
HTTP proxy settings for a number of different docker hosts.
Signed-off-by: Dave Tucker <dt@docker.com>
Upstream-commit: 6ce6ae1cd11d888e0c8ede20926b86981cee5ce1
Component: engine
