This process connects to memlogd and streams logs to individual files,
one per log. It keeps track of how many bytes have been written to each
file and rotates when the file size exceeds a defined threshold.
By default the maximum size of each file before rotation is 1MiB and
we keep up to 10 files per log.
Signed-off-by: David Scott <dave.scott@docker.com>
Looks like brtfs-prog v4.17 as shipped with alpine:3.8 requires
a loopback device of 109MB while the containerd tests only
create a 100MB device. This causes the test to fail.
Disable it until https://github.com/containerd/containerd/issues/2447
is fixed.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@gmail.com>
This simplifies the example by adding a service which writes to the
log every 1s and a getty for introspection.
To see the logs:
/proc/1/root/usr/bin/logread -F
Signed-off-by: David Scott <dave.scott@docker.com>
Switch to a more formally-specified `kmsg`-style format for reading
the logs.
- update the spec in docs/logging.md
- check for bad names in pkg/memlogd with unit test
Signed-off-by: David Scott <dave.scott@docker.com>
- check writing to the log does not block
- check the log doesn't expand -- it should be finite
- check that client connections don't buffer arbitrary amounts of
data if the client is slow
Signed-off-by: David Scott <dave.scott@docker.com>
Previously we had a per-connection
bytes.Buffer // to be written to the connection
sync.Cond // to allow us to Wait for more data
This had the major disadvantage that the buffer was unbounded and so
a slow client could cause memory exhaustion in the server. This patch
replaces these with a single
chan *logEntry
which is naturally bounded and supports blocking read. We make write
non-blocking using select i.e. we drop messages rather than allocate
more space.
Signed-off-by: David Scott <dave.scott@docker.com>
This is an example external logging service which can be enabled by
adding it to the `init` section of the .yml, for example:
...
init:
- linuxkit/init:35866bb276c264a5f664bfac7456f4b9eeb87a4d
- linuxkit/runc:v0.4
- linuxkit/containerd:f2bc1bda1ab18146967fa1a149800aaf14bee81b
- linuxkit/ca-certificates:v0.4
- linuxkit/memlogd:cc035e5c9e4011ec1ba97a181a6689fc90965ce9
onboot:
...
Signed-off-by: David Scott <dave.scott@docker.com>
If external logging is enabled, this patch sets the stdout and stderr
of the `runc` invocations to one end of a socketpair and the other end is
sent to the logging service. Otherwise we log to files as before.
Signed-off-by: David Scott <dave.scott@docker.com>
An external logging system exists if the socket
/var/run/linuxkit-external-logging.sock
exists.
If an external logging system is enabled then create FIFOs for
containerd and send the other end of the FIFOs to the logging service.
Otherwise use /var/log files as before.
Signed-off-by: David Scott <dave.scott@docker.com>
Previously memlogd would always run in the foreground. This patch
adds a `-daemonize` option which binds the /var/run sockets, forks
and execs itself and immediately returns. Therefore the program won't
block (important for an init.d script) but guarantees the sockets will
be available for any program started afterwards.
This also removes the alpine base from the memlogd image as `init`
"containers" are treated as simple file overlays.
Signed-off-by: David Scott <dave.scott@docker.com>
We will place the control sockets in the root /var/run and then share
with all services who need access.
Signed-off-by: David Scott <dave.scott@docker.com>
Since I struggled to understand and find information about how to
troubleshoot a running linuxkit instance, I propose to add these two
FAQ entries.
The first one explains why it is possible to not see the `containerd` or
`init` outputs at boot in the console.
The second one gives a few `ctr` example to list containers, running
containers or how to open a shell in a given container.
Signed-off-by: Brice Figureau <brice@daysofwonder.com>
