Missing "<timestamp> stdout F" in container log if container terminates without writing a linebreak

[syedriko]

Issue

conmon generates a partial log sequence not conforming to the CRI log spec (https://github.com/kubernetes/community/blob/master/contributors/design-proposals/node/kubelet-cri-logging.md) if container writes a sequence of characters into stdout/stderr and terminates without writing a newline.

Versions

Fedora 33

$ podman version
Version:      3.0.1
API Version:  3.0.0
Go Version:   go1.15.8
Built:        Fri Feb 19 11:56:17 2021
OS/Arch:      linux/amd64

$ conmon --version
conmon version 2.0.26
commit: 777074ecdb5e883b9bec233f3630c5e7fa37d521

How to reproduce

$ podman run busybox /bin/sh -c "echo blah | tr '\n' ' '"

Describe the results you received:

Hunt down the log for the container you just ran

$ cat ~/.local/share/containers/storage/overlay-containers/0b0250256ed0e2d675ef8ac4299aa53b20d6000a9aad25577d9e4bb210bfbb1b/userdata/ctr.log 
2021-03-29T21:16:20.753110058-04:00 stdout P blah 
$

Describe the results you expected: 2021-03-29T21:16:20.753110058-04:00 stdout P blah 2021-03-29T21:16:20.753110059-04:00 stdout F

I believe the actual behavior doesn't follow the CRI log spec and conmon should be writing out a terminating F-sequence into the log if it sees a container pipe closing without a trailing newline.

[haircommander]

hmm I am not totally convinced it's not conformant, the CRI definition is kinda vague here. Reworking the API to remember whether the last line was partial or not, and returning a full line at the end is not exactly trivial. What motivation do you have for looking for this behavior?

[syedriko]

What motivation do you have for looking for this behavior?

It would simplify what a downstream log processor like Fluentd needs to do to assemble complete log lines, from a sequence of Ps and a final F. Sure Fluentd needs to be liberal in what it accepts but issuing an F terminator would IMO make conmon more conservative in what it produces.

[haircommander]

I'm not sure I have the bandwidth to take this on, but I'd happily accept contributions :)