CertGrid CertGrid
Concepts·Podman

Podman Container Logs and Persistence

`podman rm` the container and `podman logs` says no such container - but `journalctl --user CONTAINER_NAME=talker` still prints every line. journald is the store; `podman logs` is only a reader that needs the container to exist.

Security and Operations Guide 44 of 47 Intermediate

Written against the versions above. Podman follows the distribution here rather than a vendor repository, so the version you get is the one Ubuntu shipped. The commands are stable across 5.x.

Every command on this page ran on podman01.
Server NameIP AddressOSRolesCPURAMHDD
PODMAN01192.168.0.24Ubuntu 26.04 LTSPrimary Container Host2 Core4 GB50 GB

Before you start

  1. The default driver is journald

    logdriver=journald eventsbackend=journald

    Both container output and the event stream from guide 11 go into the systemd journal. This is a real difference from Docker, whose default is a JSON file per container.

    Run something chatty and read it two ways. podman logs gives the three lines. So does journalctl --user CONTAINER_NAME=talker - the same lines, from the journal, with no Podman involved.

    That is because podman logs is querying journald, not reading a file it owns. Which means the whole journal toolset applies to container output: --since, --until, -o json, -f, filtering by unit, and shipping to a remote journal.

    bash Example session 
    podman info --format 'logdriver={{.Host.LogDriver}} eventsbackend={{.Host.EventLogger}}'logdriver=journald eventsbackend=journaldpodman run -d --name talker docker.io/library/alpine sh -c 'for i in 1 2 3; do echo "line $i from the container"; sleep 1; done; sleep 300'9b14d9e6aa5ed1bef6d8d2f621516fe92b90072522c8c2894e3a36b325b0ec35sleep 4podman logs talkerline 1 from the containerline 2 from the containerline 3 from the containerjournalctl --user CONTAINER_NAME=talker --no-pager -o catline 1 from the container line 2 from the container line 3 from the container

    Expected resultlogdriver=journald, then the same three lines from podman logs and from journalctl.

    Success conditionYou have read one container's output through two different tools.

  2. Remove the container and the logs stay

    $ podman rm -f talker
talker
$ podman logs talker
Error: no container with name or ID "talker" found
$ journalctl --user CONTAINER_NAME=talker --no-pager -o cat
line 1 from the container
line 2 from the container
line 3 from the container

    This is the one to remember. podman logs needs a container to query on your behalf, and once it is gone the command has nothing to ask about. The output was never in the container - it went to journald as it was produced, and it is still there.

    Practically: when something ran in CI, failed, and was cleaned up before you could look, podman logs is useless and journalctl is not. Between this and the event log in guide 11 - which remembered a container removed two guides earlier - the post-mortem story on Podman is genuinely good, and it is entirely journald's doing.

    Retention follows journald's rules, not Podman's. journalctl --disk-usage and SystemMaxUse in journald.conf are where container log retention is actually configured - which surprises people looking for a Podman setting.

    bash Example session 
    podman rm -f talkertime="2026-08-22T13:35:40Z" level=warning msg="StopSignal SIGTERM failed to stop container talker in 10 seconds, resorting to SIGKILL"talkerpodman logs talkerline 1 from the containerline 2 from the containerline 3 from the containerjournalctl --user CONTAINER_NAME=talker --no-pager -o catline 1 from the container line 2 from the container line 3 from the container

    Expected resultno such container from podman logs, and the three lines still in the journal.

    Success conditionYou retrieved the output of a container that no longer exists.

  3. The other driver, and why you might want it

    --log-driver=k8s-file writes a file instead:

    driver=k8s-file
path=/home/sysadmin/.local/share/containers/storage/overlay-containers/
     ac714adf815b.../userdata/ctr.log

    podman logs still works - it reads the file. And the file's format is the Kubernetes CRI log format, which is what the driver is named for:

    2026-08-22T13:35:41.558368263+00:00 stdout F written to a file

    Timestamp, stream, a full/partial flag, then the line. Any log shipper that reads Kubernetes node logs can read this unchanged.

    Meanwhile journalctl --user CONTAINER_NAME=filelog returns nothing. The output went to the file and only the file.

    Which to choose. journald for anything on a systemd host you administer: one timeline for containers and services together, structured fields, and it survives the container. k8s-file when a log shipper expects that format, when you want per-container files you can rotate independently, or on a host where journald is deliberately volatile and you need the logs on disk. --log-opt max-size=10m bounds it, which is worth setting since nothing else will.

    Also note the file lives in the container's userdata - so podman rm deletes it, and with this driver the logs do not outlive the container. That is the trade-off in one sentence.

    bash Example session 
    podman run -d --name filelog --log-driver=k8s-file docker.io/library/alpine sh -c 'echo "written to a file"; sleep 300'ac714adf815b62b1fac3537489521cb0172dd3e97c3a9c43ea906f630a937299podman inspect filelog --format 'driver={{.HostConfig.LogConfig.Type}} path={{.HostConfig.LogConfig.Path}}'driver=k8s-file path=/home/sysadmin/.local/share/containers/storage/overlay-containers/ac714adf815b62b1fac3537489521cb0172dd3e97c3a9c43ea906f630a937299/userdata/ctr.logpodman logs filelogwritten to a filecat $(podman inspect filelog --format '{{.HostConfig.LogConfig.Path}}')2026-08-22T13:35:41.558368263+00:00 stdout F written to a filejournalctl --user CONTAINER_NAME=filelog --no-pager -o catpodman rm -f filelogtime="2026-08-22T13:35:53Z" level=warning msg="StopSignal SIGTERM failed to stop container filelog in 10 seconds, resorting to SIGKILL"filelog

    Expected resultA k8s-file path under the container's userdata, a CRI-formatted line, and nothing in the journal.

    Success conditionYou can say where a given container's output is stored and whether it survives removal.

Troubleshooting

Official sources

← All Podman guides