summaryrefslogtreecommitdiffhomepage
path: root/runsc/boot/loader_test.go
AgeCommit message (Collapse)Author
2018-07-03runsc: Mount "mandatory" mounts right after mounting the root.Nicolas Lacasse
The /proc and /sys mounts are "mandatory" in the sense that they should be mounted in the sandbox even when they are not included in the spec. Runsc treats /tmp similarly, because it is faster to use the internal tmpfs implementation instead of proxying to the host. However, the spec may contain submounts of these mandatory mounts (particularly for /tmp). In those cases, we must mount our mandatory mounts before the submount, otherwise the submount will be masked. Since the mandatory mounts are all top-level directories, we can mount them right after the root. PiperOrigin-RevId: 203145635 Change-Id: Id69bae771d32c1a5b67e08c8131b73d9b42b2fbf
2018-06-29Sets the restore environment for restoring a container.Justine Olshan
Updated how restoring occurs through boot.go with a separate Restore function. This prevents a new process and new mounts from being created. Added tests to ensure the container is restored. Registered checkpoint and restore commands so they can be used. Docker support for these commands is still limited. Working on #80. PiperOrigin-RevId: 202710950 Change-Id: I2b893ceaef6b9442b1ce3743bd112383cb92af0c
2018-06-22runsc: Enable waiting on individual containers within a sandbox.Kevin Krakauer
PiperOrigin-RevId: 201742160 Change-Id: Ia9fa1442287c5f9e1196fb117c41536a80f6bb31
2018-06-21Added functionality to create a RestoreEnvironment.Justine Olshan
Before a container can be restored, the mounts must be configured. The root and submounts and their key information is compiled into a RestoreEnvironment. Future code will be added to set this created environment before restoring a container. Tests to ensure the correct environment were added. PiperOrigin-RevId: 201544637 Change-Id: Ia894a8b0f80f31104d1c732e113b1d65a4697087
2018-06-18Modified boot.go to allow for restores.Justine Olshan
A file descriptor was added as a flag to boot so a state file can restore a container that was checkpointed. PiperOrigin-RevId: 201068699 Change-Id: I18e96069488ffa3add468861397f3877725544aa
2018-06-15runsc: support /dev bind mount which does not conflict with default /dev mount.Lantao Liu
PiperOrigin-RevId: 200768923 Change-Id: I4b8da10bcac296e8171fe6754abec5aabfec5e65
2018-06-15Set kernel.applicationCores to the number of processor on the hostFabricio Voznika
The right number to use is the number of processors assigned to the cgroup. But until we make the sandbox join the respective cgroup, just use the number of processors on the host. Closes #65, closes #66 PiperOrigin-RevId: 200725483 Change-Id: I34a566b1a872e26c66f56fa6e3100f42aaf802b1
2018-06-12runsc: do not include sub target if it is not started with '/'.Lantao Liu
PiperOrigin-RevId: 200274828 Change-Id: I956703217df08d8650a881479b7ade8f9f119912
2018-05-24Configure sandbox as superuserFabricio Voznika
Container user might not have enough priviledge to walk directories and mount filesystems. Instead, create superuser to perform these steps of the configuration. PiperOrigin-RevId: 197953667 Change-Id: I643650ab654e665408e2af1b8e2f2aa12d58d4fb
2018-05-17Push signal-delivery and wait into the sandbox.Nicolas Lacasse
This is another step towards multi-container support. Previously, we delivered signals directly to the sandbox process (which then forwarded the signal to PID 1 inside the sandbox). Similarly, we waited on a container by waiting on the sandbox process itself. This approach will not work when there are multiple containers inside the sandbox, and we need to signal/wait on individual containers. This CL adds two new messages, ContainerSignal and ContainerWait. These messages include the id of the container to signal/wait. The controller inside the sandbox receives these messages and signals/waits on the appropriate process inside the sandbox. The container id is plumbed into the sandbox, but it currently is not used. We still end up signaling/waiting on PID 1 in all cases. Once we actually have multiple containers inside the sandbox, we will need to keep some sort of map of container id -> pid (or possibly pid namespace), and signal/kill the appropriate process for the container. PiperOrigin-RevId: 197028366 Change-Id: I07b4d5dc91ecd2affc1447e6b4bdd6b0b7360895
2018-05-09Return better errors from Docker when runsc fails to start.Nicolas Lacasse
Two changes in this CL: First, make the "boot" process sleep when it encounters an error to give the controller time to send the error back to the "start" process. Otherwise the "boot" process exits immediately and the control connection errors with EOF. Secondly, open the log file with O_APPEND, not O_TRUNC. Docker uses the same log file for all runtime commands, and setting O_TRUNC causes them to get destroyed. Furthermore, containerd parses these log files in the event of an error, and it does not like the file being truncated out from underneath it. Now, when trying to run a binary that does not exist in the image, the error message is more reasonable: $ docker run alpine /not/found docker: Error response from daemon: OCI runtime start failed: /usr/local/google/docker/runtimes/runscd did not terminate sucessfully: error starting sandbox: error starting application [/not/found]: failed to create init process: no such file or directory Fixes #32 PiperOrigin-RevId: 196027084 Change-Id: Iabc24c0bdd8fc327237acc051a1655515f445e68
2018-04-28Check in gVisor.Googler
PiperOrigin-RevId: 194583126 Change-Id: Ica1d8821a90f74e7e745962d71801c598c652463