- Fixup pod.getPID() to cover race between xToRun() and stage1 getting
around to writing the pid file.
- Rework `rkt enter` to retrieve the pid in rkt/stage0 and supply it to
stage1 enter.
- Rework stage1 enter to consume pid from argv instead of opening it
itself, so as to not have to duplicate the same race coverage.
- Some stage1 enter code cleanups thrown in for good measure, particularly
around the argv forwarding copy which started simple had become unwieldy.
When using overlay, the stage1 filesystem is mounted in a separate mount
namespace, rkt can't access the enter binary.
We now get the enter binary from the tree cache, using the stage1 image
the user specified when preparing/running the container.
Take two at getting the spec vendored into Rocket with Godep.
Since actool is used during the construction of the stage1.aci, it
really needs to be vendored too to prevent any unexpected divergence
between whatever version the user happens to have in their PATH. Thus,
we introduce a silly dummy package (stage1/dummy.go) to coerce Godep
into vendoring actool. This also requires a slight rearrangement of the
appc repo, moving some functionality from actool itself into the aci
package.
One may now specify an alternative stage1 in a style like run and fetch:
rkt run --stage1-image foo.com/rocket/stage1 app
--stage1-image defaults to "stage1.aci" within the same directory as the rkt
binary. This is discovered at runtime via "/proc/self/exe"; as long as the rkt
executable and stage1.aci share a directory it should "just work" regardless of
the directory's location and where rkt is executed from.
This introduces a stage1 /enter entrypoint which expects:
* the CWD to be the container root (/var/lib/rkt/containers/$cuuid)
* argv[1] to be the shorthash app imageid to enter
* argv[2] to be the command for executing via execvp
* argv[3+] any additional arguments for the command
An example manual /enter shell invocation would be:
cd /var/lib/rkt/containers/9793daa1-e064-49a6-9d52-261a992bddd8 && \
./enter sha512-9e6a3ab113ed783c1ffdcbbaa7d16f3b /bin/bash -i
"rkt enter" effectively does this after some simple argv parsing/checks and
verification of the container being presently active.
What must occur within /enter is stage1-implementation specific, hence its
inclusion within the stage1 rootfs.
The /enter implemented here consists of a statically-linked minimal C
program which:
* reads the container's PID from ./pid
* enters the namespaces of the container's PID 1
* forks to realize CLONE_NEWPID
* execs /diagexec in the child using the argv[] /enter received
* waits for the child to exit
The UX side looks like:
rkt enter [--imageid IMAGEID] UUID [CMD [ARGS ...]]
If no IMAGEID is specified, and the container is a singleton then its lone
app is entered. Otherwise a list of apps and their ids is printed and the
user must specify which app to enter in a separate invocation via --imageid.
If no cmd is specified, /bin/bash is assumed.
Examples:
Multiple images, ambiguous enter:
$ rkt enter 7324849e-80b7-4874-a14b-79de35291485
Container "7324849e-80b7-4874-a14b-79de35291485" contains multiple apps:
sha512-8a4a96dac7216ca311962d19ffa00b6c: pauser
sha512-2893e1a4714bea23ee9f21c7dd6561a4: sleeper
Unable to determine image id: specify app using "rkt enter --imageid ..."
Multiple images, specified "pauser":
$ rkt enter --imageid sha512-8a4a96dac7216ca311962d19ffa00b6c 7324849e-80b7-4874-a14b-79de35291485
No command specified, assuming "/bin/bash"
bash-4.3#
Multiple images, enter "pauser", run /pause:
$ rkt enter --imageid sha512-8a4a96dac7216ca311962d19ffa00b6c 7324849e-80b7-4874-a14b-79de35291485 /pause
paused...^C
$
Single image:
$ rkt enter 98d688dc-5665-496c-8556-f553020ccd57
No command specified, assuming "/bin/bash"
bash-4.3#
Jonathan Boulle