Go to file
Jake Hillion 04a1815319
All checks were successful
continuous-integration/drone/pr Build is passing
continuous-integration/drone/push Build is passing
fixed missing dev null
2022-05-21 16:06:04 +01:00
.vscode updated clap 2022-05-10 21:57:27 +01:00
benches added clone namespace benchmarks 2022-03-28 01:47:51 +01:00
examples fib example 2022-05-20 18:09:51 +01:00
src fixed missing dev null 2022-05-21 16:06:04 +01:00
.clang-format pipe triggers 2022-03-01 11:29:13 +00:00
.drone.yml added dronefile 2022-03-28 16:51:35 +01:00
.gitignore clone3 wrapper 2022-02-11 16:27:45 +00:00
build.rs specification and initial launching 2022-02-13 23:52:41 +00:00
Cargo.lock updated nix to 0.24.1 2022-05-19 17:18:05 +01:00
Cargo.toml updated nix to 0.24.1 2022-05-19 17:18:05 +01:00
LICENSE added license 2022-04-08 21:26:07 +01:00
README.md fib example 2022-05-20 18:09:51 +01:00

clone-shim

Running the examples

examples/fib

The fib example performs fibonacci trivially on a fixed number. It is the most basic example of a process that requires no privilege, excluding Stdout to print the result.

To run this example:

cargo build
cargo build --example fib
target/debug/clone-shim -s examples/fib/spec.json target/debug/examples/fib

examples/basic

The basic example instructs the shim to spawn two processes, each of which writes "hello from main{1,2}!" to stdout.

To run this example:

cargo build
cargo build --example basic
target/debug/clone-shim -s examples/basic/spec.json target/debug/examples/basic

examples/pipes

The pipes example shows some of the power of the shim by using pipes. The process "pipe_sender" sends two messages down a pipe that it's given by the shim. These two messages each spawn a completely isolated process, "pipe_receiver", that receives that message.

To run this example:

cargo build
cargo build --example pipes
target/debug/clone-shim -s examples/pipes/spec.json target/debug/examples/pipes

Debugging the shim

The shim can be debugged as with most processes, but it is exceptionally forky. Breaking before a clone in rust-gdb then running set follow-fork-mode child is often necessary. The best approach is to go in with a plan of attack.

Debugging the child

Debugging the child processes is vastly more difficult than in other more Linux-like containerisation solutions.

The --debug flag on the shim attempts to stop application spawned processes as soon as they are voided. This gives you a chance to attach with a debugger.

The debugger must be run from the ambient namespace and not within the void, as none of the prerequisites will exist within the void.

Good luck!