This code was added when images were saved in a factory root directory and in
addition this directory was used as a flag.
Now an user can decide when images can be removed.
Signed-off-by: Andrey Vagin <avagin@openvz.org>
CRIU has following requirements for a container root:
* it is a mount point
* a parent mount point isn't over-mounted
Signed-off-by: Andrey Vagin <avagin@openvz.org>
criu swrk allows to rollback if the /ROOT/CRID/checkpoint
file can't be created. In a future it will be used for locking network.
Signed-off-by: Andrey Vagin <avagin@openvz.org>
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>