All modern distros set up /run to be a tmpfs, see for instance:
https://wiki.debian.org/ReleaseGoals/RunDirectory
Its a very useful place to store pid-files, sockets and other things
that only live at runtime and that should not be stored in the image.
This is also useful when running systemd inside a container, as it
will try to mount /run if not already mounted, which will fail for
non-privileged container.
Docker-DCO-1.1-Signed-off-by: Alexander Larsson <alexl@redhat.com> (github: alexlarsson)
If you specify a bind mount in a place that doesn't have a file yet we
create that (and parent directories). This is needed because otherwise
you can't use volumes like e.g. /dev/log, as that gets covered by the
/dev tmpfs mounts.
Docker-DCO-1.1-Signed-off-by: Alexander Larsson <alexl@redhat.com> (github: alexlarsson)
This is a first step towards moving all code related to local
manipulation of images into a cleanly separated subsystem,
accessible via a stable set of commands in the engine API.
`graph.TagStore` now implements `engine.Installer`. For now, it
is installed by `Server.InitServer`, along with all other Server
commands. However this will change in future patches.
`graph.TagStore.Install` registers the following commands:
* `image_set` creates a new image and stores it locally.
* `image_get` returns information about an image stored locally.
* `image_tag` assigns a new name and tag to an existing image.
These commands are a pre-requisite for moving 'push' and 'pull'
out of `Server`.
Docker-DCO-1.1-Signed-off-by: Solomon Hykes <solomon@docker.com> (github: shykes)
This patch just revs the Ubuntu release used for builds from 13.10
to 14.04.
Docker-DCO-1.1-Signed-off-by: Aleksa Sarai <cyphar@cyphar.com> (github: cyphar)
The btrfs driver attempts to stat the /var/lib/docker directory to
ensure it exists. If it doesn't exist then it bails with an unhelpful
log line:
```
2014/05/10 00:51:30 no such file or directory
```
In 0.10 the directory was created but quickly digging through the logs I
can't tell what sort of re-ordering of code caused this regression.
Docker-DCO-1.1-Signed-off-by: Brandon Philips <brandon.philips@coreos.com> (github: philips)
When sending a new job to a `engine.Sender`, the corresponding
`engine.Receiver` will receive that job with its environment preserved.
Previously the job name, arguments and streams were preserved but the
env was lost.
Docker-DCO-1.1-Signed-off-by: Solomon Hykes <solomon@docker.com> (github: shykes)
* `Env.MultiMap` returns the contents of an Env as `map[string][]string`
* `Env.InitMultiMap` initializes the contents of an Env from a `map[string][]string`
This makes it easier to import and export an Env to other formats
(specifically `beam/data` messages)
Docker-DCO-1.1-Signed-off-by: Solomon Hykes <solomon@docker.com> (github: shykes)
This is a convenience for callers which are only interested in one value
per key. Similar to how HTTP headers allow multiple keys per value, but
are often used to store and retrieve only one value.
Docker-DCO-1.1-Signed-off-by: Solomon Hykes <solomon@docker.com> (github: shykes)
