In linux 5.14 and hopefully some backports, core scheduling allows processes to
be co scheduled within the same domain on SMT enabled systems.
The containerd impl sets the core sched domain when launching a shim. This
allows a clean way for each shim(container/pod) to be in its own domain and any
additional containers, (v2 pods) be be launched with the same domain as well as
any exec'd process added to the container.
kernel docs: https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/core-scheduling.html
Signed-off-by: Michael Crosby <michael@thepasture.io>
This adds valuable logging data to the open telemetry traces.
When the trace is not recording we don't bother doing anything as it is
relatively expensive to convert logrus data to otel just due to the
nature of how logrus works.
The way this works is that we now set a context on the logrus.Entry that
gets passed around which the hook then uses to determine if there is an
active span to forward the logs to.
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
The io/ioutil package has been deprecated as of Go 1.16, see
https://golang.org/doc/go1.16#ioutil. This commit replaces the existing
io/ioutil functions with their new definitions in io and os packages.
Signed-off-by: Eng Zer Jun <engzerjun@gmail.com>
Some cases can cause the server initialization to block (namely running
a 2nd containerd instance by accident against the same root dir). In
this case there is no way to quit the daemon except with `kill -9`.
This changes context things so that server init is done in a goroutine
and we wait on a channel for it to be ready while we also wait for a
ctx.Done(), which will be cancelled if there is a termination signal.
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
Go 1.15.7 contained a security fix for CVE-2021-3115, which allowed arbitrary
code to be executed at build time when using cgo on Windows. This issue also
affects Unix users who have “.” listed explicitly in their PATH and are running
“go get” outside of a module or with module mode disabled.
This issue is not limited to the go command itself, and can also affect binaries
that use `os.Command`, `os.LookPath`, etc.
From the related blogpost (ttps://blog.golang.org/path-security):
> Are your own programs affected?
>
> If you use exec.LookPath or exec.Command in your own programs, you only need to
> be concerned if you (or your users) run your program in a directory with untrusted
> contents. If so, then a subprocess could be started using an executable from dot
> instead of from a system directory. (Again, using an executable from dot happens
> always on Windows and only with uncommon PATH settings on Unix.)
>
> If you are concerned, then we’ve published the more restricted variant of os/exec
> as golang.org/x/sys/execabs. You can use it in your program by simply replacing
This patch replaces all uses of `os/exec` with `golang.org/x/sys/execabs`. While
some uses of `os/exec` should not be problematic (e.g. part of tests), it is
probably good to be consistent, in case code gets moved around.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Remove build tags which are already implied by the name of the file.
Ensures build tags are used consistently
Signed-off-by: Derek McGowan <derek@mcg.dev>
Add basic intiialization of opentelemetry including minimum support to
be able to read open telemetry config from config.toml and initialize
exporter. Tracer is initialized and ready to be be used for creating
spans, sub spans etc. With no opentelemetry configuration enabled in
config file, this patch is a no-op.
Basic config stub to be added to use opentelemetry is to add following
in config.toml. We use otlp exporter with default port 4317.
[otel]
exporter_name = "otlp"
exporter_endpoint = "0.0.0.1:4317"
otel-collector binary needs to run listening at the same port.
Signed-off-by: Alakesh Haloi <alakeshh@amazon.com>
According to the doc about `config.toml` of containerd:
```
If no version number is specified inside the config file then it is assumed to
be a version 1 config and parsed as such.
```
However, it's not true recently.
This will break the backward-compatibility in some environment.
This commit fixes this issue.
Signed-off-by: Kohei Tokunaga <ktokunaga.mail@gmail.com>
`config_linux.go` and `config_windows.go` are identical.
`config_unsupported.go` is also almost identical but enables debug logs by default.
Signed-off-by: Akihiro Suda <akihiro.suda.cz@hco.ntt.co.jp>
Previously we simply ignored any not found error when loading the
containerd config. This created unintuitive behavior:
- If the user specified a path that didn't exist via --config, we would
silently ignore the error.
- If a config specified an import that didn't exist, we would silently
ignore the error.
In either of these cases, it appears we would end up using a potentially
corrupted config, as it would contain any files that were merged into it
before the not found error was hit.
However, we can't just remove the check for !os.IsNotExist(err),
as we shouldn't throw an error when --config is not passed, but the
default config doesn't exist.
This change updates the logic to only attempt to load the config if
we know it exists, or the user passed --config.
Signed-off-by: Kevin Parsons <kevpar@microsoft.com>
If we print message when SIG_PIPE occuers in signal handler.
There is a loop {print->SIG_PIPE->print->SIG_PIPE...}, which consume
a lot of cpu time. So do not print message in this situaiton.
Signed-off-by: Liu Hua <weldonliu@tencent.com>
Go 1.14 introduced a change to os.OpenFile (and syscall.Open) on Windows
that uses the permissions passed to determine if the file should be
created read-only or not. If the user-write bit (0200) is not set, then
FILE_ATTRIBUTE_READONLY is set on the underlying CreateFile call.
This is a significant change for any Windows code which created new
files and set the permissions to 0 (previously the permissions had no
affect, so some code didn't set them at all).
This change fixes the issue for the Windows service panic file. It will
now properly be created as a non-read-only file on Go 1.14+.
I have looked over the rest of the containerd code and didn't see other
places where this seems like an issue.
Signed-off-by: Kevin Parsons <kevpar@microsoft.com>
The climan package has a command that can be registered with any urfav
cli app to generate man pages.
Signed-off-by: Michael Crosby <crosbymichael@gmail.com>
Previously the TTRPC address was generated as "<GRPC address>.ttrpc".
This change now allows explicit configuration of the TTRPC address, with
the default still being the old format if no value is specified.
As part of this change, a new configuration section is added for TTRPC
listener options.
Signed-off-by: Kevin Parsons <kevpar@microsoft.com>
EventLog is very old and provides a poor experience. We have supported
ETW for logging for a while, which is much better. We have also
observed an issue where EventLog keeps containerd.exe open, preventing
containerd from being upgraded to a new version. Due to all of this,
it makes sense to remove the old EventLog hook in favor of using ETW
logging on Windows as the primary diagnostic experience.
Signed-off-by: Kevin Parsons <kevpar@microsoft.com>
This adds a singleton `timeout` package that will allow services and user
to configure timeouts in the daemon. When a service wants to use a
timeout, it should declare a const and register it's default value
inside an `init()` function for that package. When the default config
is generated, we can use the `timeout` package to provide the available
timeout keys so that a user knows that they can configure.
These show up in the config as follows:
```toml
[timeouts]
"io.containerd.timeout.shim.cleanup" = 5
"io.containerd.timeout.shim.load" = 5
"io.containerd.timeout.shim.shutdown" = 3
"io.containerd.timeout.task.state" = 2
```
Timeouts in the config are specified in seconds.
Timeouts are very hard to get right and giving this power to the user to
configure things is a huge improvement. Machines can be faster and
slower and depending on the CPU or load of the machine, a timeout may
need to be adjusted.
Signed-off-by: Michael Crosby <crosbymichael@gmail.com>
Creating a console for containerd causes it to be inherited by any child
processes, which gives us performance and reliability improvements. See
comment in code for more information.
Another option considered here would be to invoke each child process
with the DETACHED_PROCESS flag. This would save us the containerd
console allocation. The difficulty of this approach would be ensuring
that all process invocation points have had this flag added, and that
any future invocations also use the flag.
Signed-off-by: Kevin Parsons <kevpar@microsoft.com>
