podman logs prints the captured stdout and stderr of a container, the first place to look when a service fails.
When a test container exits unexpectedly, podman logs shows why. In CI you usually dump the full log on failure so the cause is in the job output.
What it does
podman logs fetches the logs the container driver captured from the container main process. It can follow live output, show only the tail, or filter by time, mirroring docker logs.
Common usage
Terminal
podman logs db
podman logs --tail 50 db
podman logs --since 5m --timestamps db
podman logs -f app # follow (local debugging)
Options
Flag
What it does
-f, --follow
Stream new log lines as they arrive
--tail <n>
Show only the last n lines
--since <time>
Show logs after a timestamp or duration
--until <time>
Show logs before a timestamp or duration
-t, --timestamps
Prefix each line with a timestamp
-n, --names
Prefix lines with the container name
In CI
On failure, dump podman logs <name> for every service container so the error is captured in the job log before cleanup removes the container. Avoid -f in CI unless you bound it; a follow can hang the job.
Common errors in CI
Empty output often means the process logs to a file inside the container rather than stdout/stderr; podman logs only sees the main process streams. "Error: no such container" means the name is wrong or --rm already removed it; capture logs before teardown. With the journald log driver on some runners, podman logs may need the journald backend available.
Frequently asked questions
podman logs: Read Container Output in CI?
When a test container exits unexpectedly, podman logs shows why. In CI you usually dump the full log on failure so the cause is in the job output.
What it does?
podman logs fetches the logs the container driver captured from the container main process. It can follow live output, show only the tail, or filter by time, mirroring docker logs.
In CI?
On failure, dump podman logs <name> for every service container so the error is captured in the job log before cleanup removes the container. Avoid -f in CI unless you bound it; a follow can hang the job.
Common errors in CI?
Empty output often means the process logs to a file inside the container rather than stdout/stderr; podman logs only sees the main process streams. "Error: no such container" means the name is wrong or --rm already removed it; capture logs before teardown.
