golang.org/x/sys/windows now implements this, so we can use that
instead of a local implementation.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The `IsAnInteractiveSession` was deprecated, and `IsWindowsService` is marked
as the recommended replacement.
For details, see 280f808b4a
> CL 244958 includes isWindowsService function that determines if a
> process is running as a service. The code of the function is based on
> public .Net implementation.
>
> IsAnInteractiveSession function implements similar functionality, but
> is based on an old Stackoverflow post., which is not as authoritative
> as code written by Microsoft for their official product.
>
> This change copies CL 244958 isWindowsService function into svc package
> and makes it public. The intention is that future users will prefer
> IsWindowsService to IsAnInteractiveSession.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Previously we were reassigning os.Stderr to the panic.log file we create
when getting asked to run Containerd as a Windows service. The panic.log
file was used as a means to easily collect panic stacks as Windows
services don't have regular standard IO, and the usual recommendation
is to either write to the event log or just to a file in the case of
running as a service.
One place where this panic.log flow was biting us was with shim logging,
which is forwarded from the shim and copied to os.Stderr directly which was
causing shim logs to get forwarded to this panic.log file instead of just
panics. We expose an additional `--log-file` flag if you ask to run a
windows service which is the main way you'd get Containerd logs, and with
this change all of the shim logging which would today end up in panic.log
will now also go to this log file.
Signed-off-by: Daniel Canter <dcanter@microsoft.com>
With google.golang.org/protobuf, proto-generated objects only have
ProtoReflect(). They don't have Marshal() anymore (see #6564).
Signed-off-by: Kazuyoshi Kato <katokazu@amazon.com>
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>
