The buffer is used to read from the stderr/stdout stream, which
can easily be larger than 256 bytes. With a larger buffer we will
do fewer, larger reads, which is more efficient. And 8k more stack
size use is not really a problem.
Signed-off-by: Alexander Larsson <alexl@redhat.com>
The code as is doesn't handle merged controllers.
For instance, I have this in my /proc/self/cgrous:
4:cpu,cpuacct:/user.slice/user-0.slice/session-4.scope
The current code fails to match "cpuacct" wit this line, and
additionally it just does a prefix match so if you were looking
for say "cpu", it would match this:
2:cpuset:/
I also removed some ninfo spew that didn't seem very useful.
Signed-off-by: Alexander Larsson <alexl@redhat.com>
Rather than writing the logs with one write per line, use writev()
to write multiple lines in one call. Additionally, this avoids
using dprintf() when writing to the log, which is nice because that
doesn't correctly handle partial writes or ENOINTR.
This also changes set_k8s_timestamp to add the pipe to the reused
buffer so that we don't have to append it on each line.
Signed-off-by: Alexander Larsson <alexl@redhat.com>
Any write could be interupted by EINTR if we get some kind of signal,
which means we could be either reporting a EINTR error or a partial
write (if some data was written). Its also generally good to handle
partial writes correctly, as they can happen e.g. when writing to
full pipes.
Signed-off-by: Alexander Larsson <alexl@redhat.com>
conmon has many flags that are parsed when it's executed, one of them
is "-c". During PR #510 where we vendor latest kube master code,
upstream has changed a test to call a "ctr execsync" with a command of
"sh -c commmand ...".
Turns out:
a) conmon has a "-c" flag which refers to the container name/id
b) the exec command has a "-c" flags but it's for "sh"
That leads to conmon parsing the second "-c" flags from the exec
command causing an error. The executed command looks like:
conmon -c [..other flags..] CONTAINERID -e sh -c echo hello world
This patch rewrites the exec sync code to not pass down to conmon the
exec command via command line. Rather, we're now creating an OCI runtime
process spec in a temp file, pass _the path_ down to conmon, and have
runc exec the command using "runc exec --process
/path/to/process-spec.json CONTAINERID". This is far better in which we
don't need to bother anymore about conflicts with flags in conmon.
Added and fixed some tests also.
Signed-off-by: Antonio Murdaca <runcom@redhat.com>
The ocid project was renamed to CRI-O, months ago, it is time that we moved
all of the code to the new name. We want to elminate the name ocid from use.
Move fully to crio.
Also cric is being renamed to crioctl for the time being.
Signed-off-by: Dan Walsh <dwalsh@redhat.com>
Now that conmon splits std{out,err} for !terminal containers, ExecSync
can parse that output to return the correct std{out,err} split to the
kubelet. Invalid log lines are ignored but complained about.
Signed-off-by: Aleksa Sarai <asarai@suse.de>
While it's not currently possible to do this for terminal=true
containers, for !terminal containers we can create separate pipes for
stdout and stderr, and then log them separately. This is required for
k8s's conformance tests.
Signed-off-by: Aleksa Sarai <asarai@suse.de>
The CRI requires us to prepend (timestamp, stream) to every line of the
output, and it's quite likely (especially in the !terminal case) that we
will read more than one line of output in the read loop.
So, we need to write out each line separately with the prepended
timestamps. Doing this the simple way (the final part of the buffer is
written partially if it doesn't end in a newline) makes the code much
simpler, with the downside that if we ever switch to multiple streams
for output we'll have to rewrite parts of this.
In addition, drop the debugging output of cri-o for each chunk read so
we stop spamming stderr. We can do this now because 8a928d06e7
("oci: make ExecSync with ExitCode != 0 act properly") actually fixed
how ExecSync was being handled (especially in regards to this patch).
Fixes: 1dc4c87c93 ("conmon: add timestamps to logs")
Signed-off-by: Aleksa Sarai <asarai@suse.de>
CRI requires us to timestamp our logs line-by-line by specifying whether
the line came from std{out,err} and the time at which the log was
recieved. This is a preliminary implementation of said behaviour
(without explicit newline handling at the moment).
Signed-off-by: Mrunal Patel <mpatel@redhat.com>
Signed-off-by: Aleksa Sarai <asarai@suse.de>
While pipes have their downsides, it turns out that socketpair(2) will
break any program that tries to open /dev/std{out,err} for writing
(because they're symlinked to /proc/1/fd/{1,2} which will cause lots of
fun issues with sockets).
Signed-off-by: Mrunal Patel <mpatel@redhat.com>
Signed-off-by: Aleksa Sarai <asarai@suse.de>
This adds a very simple implementation of logging within conmon, where
every buffer read from the masterfd of the container is also written to
the log file (with errors during writing to the log file ignored).
Signed-off-by: Aleksa Sarai <asarai@suse.de>
Some OCI container runtimes (in particular the hypervisor
based ones) will typically create a shim process between
the hypervisor and the runtime caller, in order to not
rely on the hypervisor process for e.g. forwarding the
output streams or getting a command exit code.
With these runtimes we need to monitor a different process
than the runtime one when executing a command inside a
running container. The natural place to do so is conmon
and thus we add a new option to conmon for calling the
runtime exec command, monitor the PID and then return the
running command exit code through the sync pipe to the
parent.
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
waitpid fills its second argument with a value that
contains the process exit code in the 8 least significant
bits. Instead of returning the complete value and then
convert it from ocid, return the exit status directly
by using WEXITSTATUS from conmon.
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
We need to be able pass both the bundle path and the pid file
paths to conmon from ocid.
The former is mandatory when creating an OCI container:
https://github.com/opencontainers/runtime-spec/blob/master/runtime.md#create
And it makes sense to provide a full path for the latter as the
current hardcoded relative path may lead to errors if e.g. the
runtime chdir() before creating the PID file.
In both cases we try to create default reasonable values when
they are left empty by the caller.
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
conmon uses getopt() even if it's a glib based application,
and therefore could use the much more modern and flexible
GOptionContext mechanism. Fixes#89
Signed-off-by: Alvaro Lopez Ortega <alvaro@gnu.org>
