vendor/src/github.com/golang/protobuf/proto/all_test.go:1284: result of fmt.Sprintf call not used
Do we really need to execute go vet for vendor? I don't find how to exclude them.
Signed-off-by: Andrey Vagin <avagin@openvz.org>
criu swrk is a special mode when we don't want to execute a service,
but want to use RPC.
Here is more details:
http://lists.openvz.org/pipermail/criu/2015-March/019400.html
Another good feature of this mode is that we don't need to create
action scripts and we will be able to remove the hack with saving StdFds.
criu swrk is supported starting with CRIU 1.5.1.
Signed-off-by: Andrey Vagin <avagin@openvz.org>
This is work in progress, integrating C/R support from
https://github.com/SaiedKazemi/docker/tree/cr into the
new libcontainer and nsinit.
Signed-off-by: Saied Kazemi <saied@google.com>
Also use pipes for non tty so that the parent's tty of the nsinit
process does not leak into the conatiner.
Signed-off-by: Michael Crosby <crosbymichael@gmail.com>
Commit 4d1d6185ab added this nsenter_unsupported.go file in order for nsenter to be a valid (but empty, non-functional) Go package on unsupported platforms. However, on such platforms, Go still complains because there exists a .c file in this folder, but the package doesn't use cgo.
Fix that by importing "C" pseudo-package.
Signed-off-by: Dmitri Shuralyov <shurcooL@gmail.com>
According to https://golang.org/src/runtime/symtab.go?s=3423:3455#L94
It is possibile that runtime.FuncForPC() returns nil, don't know how
but I do met this problem when some kernel config problems cause
`p.createNetworkInterfaces` return error.
panic: runtime error: invalid memory address or nil pointer dereference
[signal 0xb code=0x1 addr=0x0]
goroutine 74 [running]:
github_com_docker_libcontainer_stacktrace.NewFrame
/go/src/github.com/docker/docker/vendor/src/github.com/docker/libcontainer/stacktrace/frame.go:12
github_com_docker_libcontainer_stacktrace.Capture
/go/src/github.com/docker/docker/vendor/src/github.com/docker/libcontainer/stacktrace/capture.go:18
libcontainer.newSystemError
/go/src/github.com/docker/docker/vendor/src/github.com/docker/libcontainer/generic_error.go:48
github_com_docker_libcontainer.start.pN42_github_com_docker_libcontainer.initProcess
/go/src/github.com/docker/docker/vendor/src/github.com/docker/libcontainer/process_linux.go:177
github_com_docker_libcontainer.Start.pN45_github_com_docker_libcontainer.linuxContainer
/go/src/github.com/docker/docker/vendor/src/github.com/docker/libcontainer/container_linux.go:102
github_com_docker_docker_daemon_execdriver_native.Run.pN56_github_com_docker_docker_daemon_execdriver_native.driver
/go/src/github.com/docker/docker/.gopath/src/github.com/docker/docker/daemon/execdriver/native/driver.go:149
github_com_docker_docker_daemon.Run.pN38_github_com_docker_docker_daemon.Daemon
/go/src/github.com/docker/docker/.gopath/src/github.com/docker/docker/daemon/daemon.go:1007
github_com_docker_docker_daemon.Start.pN48_github_com_docker_docker_daemon.containerMonitor
/go/src/github.com/docker/docker/.gopath/src/github.com/docker/docker/daemon/monitor.go:138
promise.$nested0
/go/src/github.com/docker/docker/.gopath/src/github.com/docker/docker/pkg/promise/promise.go:8
created by github_com_docker_docker_pkg_promise.Go
/go/src/github.com/docker/docker/.gopath/src/github.com/docker/docker/pkg/promise/promise.go:7
Signed-off-by: Qiang Huang <h.huangqiang@huawei.com>
Allowing mounts in containers is dangerous. Bugs in
mount namespaces or quirks of the container configuration
could allow for various breakouts.
By default, processes in containers will not be able to mount anyway,
rendering the allowances in the default AppArmor profile nearly
useless. Manually created sub-containers were able to mount, but
were yet restricted from performing most of the mounts flags indicated
in the profile.
Signed-off-by: Eric Windisch <eric@windisch.us>
We need to do this incase /dev/null is a symlink pointing somewhere
outside the container's rootfs.
Signed-off-by: Michael Crosby <crosbymichael@gmail.com>
User specified mounts much be evaluated after each mount because
symlinks in nested mounts can invalidate the next mount.
Also check that any bind mounts are not inside /proc or /sys to ensure
that we are able to mask over certian paths inside.
Signed-off-by: Michael Crosby <crosbymichael@gmail.com>