This commits an initial version of the Memorizer tracing tool. It collects and
outputs detailed data on the objects (traced from kmalloc/kmem_cache_alloc) and
accesses, tracking the context of each event with respect to thread ID, program
counter, and for allocations name of process.
Signed-off-by: Nathan Dautenhahn <ndd@cis.upenn.edu>
Since these are the user login containers, having the ability to add packages
is useful (e.g. I quite often find I want strace).
Doing this requires that we not share `/var` with the login containers since we
want the apk database therein. Previously it was thought that the containers
might need some parts of `/var` for `ctr` to work (e.g. `/var/lib/containerd`)
but this is not the case now (if it ever was) based on my testing.
Fixes#2206.
Signed-off-by: Ian Campbell <ijc@docker.com>
This is actually containerd#1141 rebased onto v1.0.0-alpha1.
The `dist` command has been integreated into `ctr` and so is removed, including
from the getty and sshd bind mounts and the test which uses it is updated..
There is no change to the version of runc vendored by containerd, so this is
unchanged.
Signed-off-by: Ian Campbell <ijc@docker.com>
If the configuration .json has contents like:
{
"etc": {
"ssl": {
"certs": {
"ca-certificates.crt": {
"perm": "0644",
"content": "large amount of certificate text"
}
}
}
},
...
}
then we print a warning because the node "ssl" has no "perm".
Previously the warning would include the contents of "ssl", which
would be large (and in theory could include secret information).
This patch modifies the warning print to only print the key and
not the value.
Without this patch, I see on the console:
2017/07/20 10:03:04 CDROM: Probe succeeded
2017/07/20 10:03:04 No permission provided ssl:map[certs:map[ca-certificates.crt:map[perm:0644 content:large amount of certificate text]]]
- 000-metadata
With this patch, I see on the console:
2017/07/20 09:54:18 CDROM: Probe succeeded
2017/07/20 09:54:18 No permission provided ssl
- 000-metadata
Signed-off-by: David Scott <dave.scott@docker.com>
It's slightly embarrassing that this old snapshot was kept around here
rotting for so long, but thankfully something is finally being done
about it.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
I noticed that running the runes in docs/vendoring.md made a bunch of files
which are omitted by modern vndr come back, presumably due to the old version
of vndr referenced there. So update the go-compile package to the current
version everywhere.
Also correct the use of `make` variable syntax (`$(PWD)`) where shell syntax
command substitution for `pwd` was desired.
Signed-off-by: Ian Campbell <ijc@docker.com>
The sample init script from opengcs is quite basic (and doesn't
set up several mounts and symlinks). Use the relevant portion
from rc.init from the LinuxKit init package instead.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
Apart from adding the recursive target itself this required:
- Unescaping the @ in the image names, this was confusing `make` into always
rebuilding and wasn't necessary (I had previously thought I had seen oddities
due to these being interpreted by the `patsubst`, but I think that was just the
colons.
- Making the recursive rules silent (prepending an @), those command lines are
not especially enlightening and they obscure the output in the show-tags case.
With this the output is like:
$ make --no-print-directory -C image-cache/ show-tags
linuxkitprojects/kubernetes-image-cache-common:94a0715c6b3604e909bc0da74260dc7f1142d90d-dirty
linuxkitprojects/kubernetes-image-cache-control-plane:94a0715c6b3604e909bc0da74260dc7f1142d90d-dirty
Signed-off-by: Ian Campbell <ijc@docker.com>
The total size of the images in the common and control-plane cache is 251M and
528M respectively.
This changes drops the size of the cache images from 353M to 274M and from 630M
to 530M, reducing the overhead from ~100M to ~20M.
The initrd images shrink from 273M to 246M and from 416M to 363M (the initrd's
are compressed).
Signed-off-by: Ian Campbell <ijc@docker.com>
This updates the build of the two image caches to use the `pkg/package.mk`
infrastructure, albeit in a slightly (ok, very) atypical way.
In order to share the bulk of the build code (including the `Dockerfile` and
the `Makefile` machinery to download the images) we arrange for the necessary
bits to be copied at build time into distinct subdirectories and for the
`pkg/package.mk` to be aware of this possibility.
Since pkg/package.mk is only set up to build a single package we use a single
`image-cache/Makefile` to drive the whole process and recurse into
`Makefile.pkg` to build individual packages.
One particular subtlety is that the package hash is based on the `image-cache`
directory (which is in `git`) rather than the generated subdirectories (which
are not in `git`). Since all the generators (and their inputs) are in the
`image-cache` directory this is what we want. This means that the two images
are given the same tag, but this is deliberate and desirable.
The generated directories are completely temporary to avoid picking up stale
versions of images when versions are updated. Images are hardlinked into place.
The images are moved to the linuxkitprojects org. Using a dev tag for now, will
update once everything is in place.
Also use "tag" rather than "build" where appropriate in the Makefile.
There is no point in the .dockerignore now, but add a .gitignore.
Signed-off-by: Ian Campbell <ijc@docker.com>
