podman logs: Read Container Output in CI
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
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.