Closed void-spark closed 1 year ago
that is expected with passthrough, the unit name is the one used for the container scope. With the journald driver, conmon takes care to forward the logs to journald and we have the possibility to set these fields, but that cannot be done with passthrough since the container std streams communicate directly with systemd
I guess creating the machine-libpod_pod_8a3046eac4cf9a98bff90e8de88a7cae529fa6d2a04983358a7ef523282119f5.slice slice is just part of how kube play works, right? :)
Yes this is how it works. Note that we changed the default back in v4.5 to the journald driver. And also podman logs will be able to read quadlet logs when log-driver passthrough is used.
I wonder if it's better to suggest journald to be the default, it does add far more (and more useful) fields to the log. I'm guessing that systemd pretty much doesn't see the processes in the container as part of the unit anymore, since they are in a cgroups slice unrelated to it, which you also see in status:
It does still log the stdout since it's connected, but with the details from the process in the container, which it no longer see as part of the unit, something like that.. :)
Issue Description
When using quadlet with a kube unit on 4.4.1-rhel, which forces --log-driver passthrough (which also seems to be recommended for running under systemd), container log entries are passed via stdout to systemd. But somehow the setup with quadlet .kube results in neither of the fields that journalctl -u checks having the unit name: "_SYSTEMD_SLICE" : "machine-libpod_pod_8a3046eac4cf9a98bff90e8de88a7cae529fa6d2a04983358a7ef523282119f5.slice", "_SYSTEMD_UNIT" : "libpod-880dad3c30ef460805d64e04d6c47560bfaa7e7e4ff28806aba710b48f4aa9c7.scope", It seems that SYSLOG_IDENTIFIER is set to the unit name for some reason, so to get all logs for the unit (what's logged by podman process, and the container stdout) I can do this: journalctl -f _SYSTEMD_UNIT=myservice.service + SYSLOG_IDENTIFIER=myservice But that's not great :)
I tried using LogExtraFields to set a marker for the unit, but I found out that actually works by matching against the unit name, so it's also ignored for those container log messages.
The fields are obviously set by systemd, and I'm guessing they reflect some special voodoo (to me :) ) that podman does with the containers, I don't know enough to say if this is a bug/issue with systemd, or with how journalctl looks at log records, or a inconvenient result of some good choices in how podman sets things up.
The workaround would be to switch back to --log-driver journald, which for this version means not using quadlet, since it's hardcoded (next version I could).
rpm -q podman: podman-4.4.1-9.el9_2.x86_64
Note: On RH 9.2 now, so podman 4.4.1 from the 4.4.1-rhel branch. Red hat doesn't offer a newer version of podman than that to test with. For tests I'm using Rocky, but it should be/seems to be identical to RH
Steps to reproduce the issue
Steps to reproduce the issue
Describe the results you received
No container logs when using journalctl -u
Describe the results you expected
Container logs when using journalctl -u
podman info output
Podman in a container
No
Privileged Or Rootless
Privileged
Upstream Latest Release
No
Additional environment details
WSL2 for tests
Additional information
No response