Refactor configuring logging into a reusable component
so that it can be nicely used in both main() and init process init()
Co-authored-by: Georgi Sabev <georgethebeatle@gmail.com>
Co-authored-by: Giuseppe Capizzi <gcapizzi@pivotal.io>
Co-authored-by: Claudia Beresford <cberesford@pivotal.io>
Signed-off-by: Danail Branekov <danailster@gmail.com>
Add support for children processes logging (including nsexec).
A pipe is used to send logs from children to parent in JSON.
The JSON format used is the same used by logrus JSON formatted,
i.e. children process can use standard logrus APIs.
Signed-off-by: Marco Vedovati <mvedovati@suse.com>
This PR decomposes `libcontainer/configs.Config.Rootless bool` into `RootlessEUID bool` and
`RootlessCgroups bool`, so as to make "runc-in-userns" to be more compatible with "rootful" runc.
`RootlessEUID` denotes that runc is being executed as a non-root user (euid != 0) in
the current user namespace. `RootlessEUID` is almost identical to the former `Rootless`
except cgroups stuff.
`RootlessCgroups` denotes that runc is unlikely to have the full access to cgroups.
`RootlessCgroups` is set to false if runc is executed as the root (euid == 0) in the initial namespace.
Otherwise `RootlessCgroups` is set to true.
(Hint: if `RootlessEUID` is true, `RootlessCgroups` becomes true as well)
When runc is executed as the root (euid == 0) in an user namespace (e.g. by Docker-in-LXD, Podman, Usernetes),
`RootlessEUID` is set to false but `RootlessCgroups` is set to true.
So, "runc-in-userns" behaves almost same as "rootful" runc except that cgroups errors are ignored.
This PR does not have any impact on CLI flags and `state.json`.
Note about CLI:
* Now `runc --rootless=(auto|true|false)` CLI flag is only used for setting `RootlessCgroups`.
* Now `runc spec --rootless` is only required when `RootlessEUID` is set to true.
For runc-in-userns, `runc spec` without `--rootless` should work, when sufficient numbers of
UID/GID are mapped.
Note about `$XDG_RUNTIME_DIR` (e.g. `/run/user/1000`):
* `$XDG_RUNTIME_DIR` is ignored if runc is being executed as the root (euid == 0) in the initial namespace, for backward compatibility.
(`/run/runc` is used)
* If runc is executed as the root (euid == 0) in an user namespace, `$XDG_RUNTIME_DIR` is honored if `$USER != "" && $USER != "root"`.
This allows unprivileged users to allow execute runc as the root in userns, without mounting writable `/run/runc`.
Note about `state.json`:
* `rootless` is set to true when `RootlessEUID == true && RootlessCgroups == true`.
Signed-off-by: Akihiro Suda <suda.akihiro@lab.ntt.co.jp>
According to the XDG specification[1], in order to avoid the possibility of
our container states being auto-pruned every 6 hours we need to set the
sticky bit. Rather than handling all of the users of --root, we just
create the directory and set the sticky bit during detection, as it's
not expensive.
[1]: https://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html
Signed-off-by: Aleksa Sarai <asarai@suse.de>
Updated logrus to use v1 which includes a breaking name change Sirupsen -> sirupsen.
This includes a manual edit of the docker term package to also correct the name there too.
Signed-off-by: Steven Hartland <steven.hartland@multiplay.co.uk>
`urfave/cli` now takes upon itself to log the error returned by the
command action directly. This means that by default the `--log` option
was ignored upon error.
This commit ensure that `urfave/cli.ErrWriter` will use logrus
Signed-off-by: Kenfe-Mickael Laventure <mickael.laventure@gmail.com>
When we set a wrong --log-format value, runc exit without any
message:
# ./runc --log-format aaa list
#
It is again "no news is good news" rule.
And it is not unified with the case when we set a wrong --log
value:
# ./runc --log / list
ERRO[0000] open /: is a directory
open /: is a directory
#
This patch unified action for above two error-setting.
After patch:
# ./runc --log-format aaa list
unknown log-format: "aaa"
#
Signed-off-by: Zhao Lei <zhaolei@cn.fujitsu.com>
This ensures that anything written to the logs are synced as they
happen.
This also changes the error message of the libcontainer error. The
original idea was to have this extra information in the message but it
makes it hard to parse and if the caller needed this information they
can just get it from the error type.
Signed-off-by: Michael Crosby <crosbymichael@gmail.com>
The error handling on the runc cli is currenly pretty messy because
messages to the user are split between regular stderr format and logrus
message format. This changes all the error reporting to the cli to only
output on stderr and exit(1) for consumers of the api.
By default logrus logs to /dev/null so that it is not seen by the user.
If the user wants extra and/or structured loggging/errors from runc they
can use the `--log` flag to provide a path to the file where they want
this information. This allows a consistent behavior on the cli but
extra power and information when debugging with logs.
This also includes a change to enable the same logging information
inside the container's init by adding an init cli command that can share
the existing flags for all other runc commands.
Signed-off-by: Michael Crosby <crosbymichael@gmail.com>
Closes#532
This requires the container id to always be passed to all runc commands
as arg one on the cli. This was the result of the last OCI meeting and
how operations work with the spec.
Signed-off-by: Michael Crosby <crosbymichael@gmail.com>
By adding detach to runc the container process is the only thing running
on the system is the containers process.
This allows better usage of memeory and no runc process being long
lived. With this addition you also need a delete command because the
detached container will not be able to remove state and the left over
cgroups directories.
Signed-off-by: Michael Crosby <crosbymichael@gmail.com>
I deleted possibility to specify config file from commands for now.
Until we decide how it'll be done. Also I changed runc spec interface to
write config files instead of output them.
Signed-off-by: Alexander Morozov <lk4d4@docker.com>
When any non-global-flag parameter appears on the command line make sure
there's a "command" even in the 'start' (run) case to ensure its not
ambiguous as to what the arg is. For example, w/o this fix its not
clear if
runc foo
means 'foo' is the name of a config file or an unknown command. Or worse,
you can't name a config file the same a ANY command, even future (yet to
be created) commands.
We should fix this now before we ship 1.0 and are forced to support this
ambiguous case for a long time.
Signed-off-by: Doug Davis <dug@us.ibm.com>
Danail Branekov
Marco Vedovati
Akihiro Suda
Aleksa Sarai
Giuseppe Scrivano
Steven Hartland
Kenfe-Mickael Laventure
Mrunal Patel
rajasec
Michael Crosby
Qiang Huang
Zhao Lei
Mike Brown
Alexander Morozov
xlgao-zju
Tianon Gravi
Marcos Lilljedahl
Eric Myhre
Lai Jiangshan
Mrunal Patel
Doug Davis