When signal installation was moved to a goroutine for performance,
containers that exited quickly could complete before SIGCHLD was
registered, causing runc to hang waiting for the signal.
This fix ensures SIGCHLD is registered immediately in the main thread
before other signals are handled in the goroutine, maintaining performance
while guaranteeing no missed SIGCHLD notifications for fast-exiting
containers.
Reported-by: Ayato Tokubi <atokubi@redhat.com>
Signed-off-by: lifubang <lifubang@acmcoder.com>
For detached container, we don't need to setup signal notifier, because
there is no customer to consume the signals in `forward()`.
Signed-off-by: lifubang <lifubang@acmcoder.com>
In fact, notifySocket has no relationship to signalHandler, we
can move it out of signalHandler to make the code more clear.
Signed-off-by: lifubang <lifubang@acmcoder.com>
This way, given a recent Go and Linux version, pidfd_send_signal will
be used under the hood.
Keep unix.Signal and unix.SignalName for logging (it is way more
readable than what os.Signal.String() provides).
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
There is a big loop(at least 65 times) in `signal.Notify`, it costs as much
time as `runc init`, so we can call it in parallel ro reduce the container
start time. In a general test, it can be reduced about 38.70%.
Signed-off-by: lifubang <lifubang@acmcoder.com>
(cyphar: move signal channel definition inside goroutine)
Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>
golangci-lint v1.54.2 comes with errorlint v1.4.4, which contains
the fix [1] whitelisting all errno comparisons for errors coming from
x/sys/unix.
Thus, these annotations are no longer necessary. Hooray!
[1] https://github.com/polyfloyd/go-errorlint/pull/47
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
Foreground runc exec and runc run forwards all the signals (that it can)
to the process being run.
Since Go 1.14, go runtime uses SIGURG for async preemptive scheduling.
This means that runc regularly receives SIGURG and, in case of
foreground runc run/exec, it gets forwarded to the container process.
For example:
[kir@kir-rhat runc]$ sudo ./runc --debug exec xx67 sleep 1m
...
DEBU[0000] child process in init()
DEBU[0000] setns_init: about to exec
DEBU[0000]signals.go:102 main.(*signalHandler).forward() sending signal to process urgent I/O condition
DEBU[0000]signals.go:102 main.(*signalHandler).forward() sending signal to process urgent I/O condition
DEBU[0000]signals.go:102 main.(*signalHandler).forward() sending signal to process urgent I/O condition
...
Or, with slightly better debug messages from commit 58c1ff39a5:
DEBU[0000]signals.go:102 main.(*signalHandler).forward() forwarding SIGURG to 819784
DEBU[0000]signals.go:102 main.(*signalHandler).forward() forwarding SIGURG to 819784
Obviously, this signal is an internal implementation detail of Go
runtime, and should not be forwarded to the container process.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
Here's how it looks now:
$ runc --debug exec ctid sleep 1h
...
DEBU[0000]signals.go:102 main.(*signalHandler).forward() sending signal to process urgent I/O condition
DEBU[0000]signals.go:102 main.(*signalHandler).forward() sending signal to process urgent I/O condition
DEBU[0022]signals.go:102 main.(*signalHandler).forward() sending signal to process terminated
DEBU[0022]signals.go:102 main.(*signalHandler).forward() sending signal to process urgent I/O condition
This is obviously not very readable.
Use unix.SignalName, plus a numeric representation of the signal, since
SignalName does not know all signals.
Add PID while we're at it.
With this commit:
DEBU[0000]signals.go:103 main.(*signalHandler).forward() forwarding signal 23 (SIGURG) to 891345
DEBU[0020]signals.go:103 main.(*signalHandler).forward() forwarding signal 45 () to 891345
DEBU[0020]signals.go:103 main.(*signalHandler).forward() forwarding signal 23 (SIGURG) to 891345
DEBU[0020]signals.go:103 main.(*signalHandler).forward() forwarding signal 23 (SIGURG) to 891345
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
This was added by commit 5aa82c950 back in the day when we thought
runc is going to be cross-platform. It's very clear now it's Linux-only
package.
While at it, further clarify it in README that we're Linux only.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
Errors from unix.* are always bare and thus can be used directly.
Add //nolint:errorlint annotation to ignore errors such as these:
libcontainer/system/xattrs_linux.go:18:7: comparing with == will fail on wrapped errors. Use errors.Is to check for a specific error (errorlint)
case errno == unix.ERANGE:
^
libcontainer/container_linux.go:1259:9: comparing with != will fail on wrapped errors. Use errors.Is to check for a specific error (errorlint)
if e != unix.EINVAL {
^
libcontainer/rootfs_linux.go:919:7: comparing with != will fail on wrapped errors. Use errors.Is to check for a specific error (errorlint)
if err != unix.EINVAL && err != unix.EPERM {
^
libcontainer/rootfs_linux.go:1002:4: switch on an error will fail on wrapped errors. Use errors.Is to check for specific errors (errorlint)
switch err {
^
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
In many places (not all of them though) we can use `unix.`
instead of `syscall.` as these are indentical.
In particular, x/sys/unix defines:
```go
type Signal = syscall.Signal
type Errno = syscall.Errno
type SysProcAttr = syscall.SysProcAttr
const ENODEV = syscall.Errno(0x13)
```
and unix.Exec() calls syscall.Exec().
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
if NOTIFY_SOCKET is used, do not block the main runc process waiting
for events on the notify socket. Bind mount the parent directory of
the notify socket, so that "start" can create the socket and it is
still accessible from the container.
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
Fixes a race that occurred very frequently in testing where the tty of
the container may be closed by the time that runc gets to sending
SIGWINCH. This failure mode is not fatal, but it would cause test
failures due to expected outputs not matching. On further review it
appears that the original addition of these checks in 4c5bf649d0
("Check error return values") was actually not necessary, so partially
revert that change.
The particular failure mode this resolves would manifest as error logs
of the form:
time="2017-08-24T07:59:50Z" level=error msg="bad file descriptor"
Fixes: 4c5bf649d0 ("Check error return values")
Signed-off-by: Aleksa Sarai <asarai@suse.de>
Both tty.resize and notifySocket.setupSocket return an error which isn't
handled in the caller. Fix this and either log or propagate the errors.
Found using https://github.com/mvdan/unparam
Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
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>
Since syscall is outdated and broken for some architectures,
use x/sys/unix instead.
There are still some dependencies on the syscall package that will
remain in syscall for the forseeable future:
Errno
Signal
SysProcAttr
Additionally:
- os still uses syscall, so it needs to be kept for anything
returning *os.ProcessState, such as process.Wait.
Signed-off-by: Christy Perez <christy@linux.vnet.ibm.com>
The current support of systemd-notify has a race condition as the
message send to the systemd notify socket might be dropped if the sender
process is not running by the time systemd checks for the sender of the
datagram. A proper fix of this in systemd would require changes to the
kernel to maintain the cgroup of the sender process when it is dead (but
it is not probably going to happen...)
Generally, the solution to this issue is to specify the PID in the
message itself so that systemd has not to guess the sender, but this
wouldn't work when running in a PID namespace as the container will pass
the PID known in its namespace (something like PID=1,2,3..) and systemd
running on the host is not able to map it to the runc service.
The proposed solution is to have a proxy in runc that forwards the
messages to the host systemd.
Example of this issue:
https://github.com/projectatomic/atomic-system-containers/pull/24
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
This implements {createTTY, detach} and all of the combinations and
negations of the two that were previously implemented. There are some
valid questions about out-of-OCI-scope topics like !createTTY and how
things should be handled (why do we dup the current stdio to the
process, and how is that not a security issue). However, these will be
dealt with in a separate patchset.
In order to allow for late console setup, split setupRootfs into the
"preparation" section where all of the mounts are created and the
"finalize" section where we pivot_root and set things as ro. In between
the two we can set up all of the console mountpoints and symlinks we
need.
We use two-stage synchronisation to ensures that when the syscalls are
reordered in a suboptimal way, an out-of-place read() on the parentPipe
will not gobble the ancilliary information.
This patch is part of the console rewrite patchset.
Signed-off-by: Aleksa Sarai <asarai@suse.de>
We need to make sure the container is destroyed before closing the stdio
for the container. This becomes a big issues when running in the host's
pid namespace because the other processes could have inherited the stdio
of the initial process. The call to close will just block as they still
have the io open.
Calling destroy before closing io, especially in the host pid namespace
will cause all additional processes to be killed in the container's
cgroup. This will allow the io to be closed successfuly.
This change makes sure the order for destroy and close is correct as
well as ensuring that if any errors encoutered during start or exec will
be handled by terminating the process and destroying the container. We
cannot use defers here because we need to enforce the correct ordering
on destroy.
This also sets the subreaper setting for runc so that when running in
pid host, runc can wait on the addiontal processes launched by the
container, useful on destroy, but also good for reaping the additional
processes that were launched.
Signed-off-by: Michael Crosby <crosbymichael@gmail.com>
Should compile now without errors but changes needed to be added for each system so it actually works.
main_unsupported.go is a new file with all the unsupported commands
Fixes#9
Signed-off-by: Marianna <mtesselh@gmail.com>
Rodrigo Campos Catelin